You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/cpp2/expressions.md
+7-8Lines changed: 7 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,20 +186,20 @@ Here are some `as` casts with their Cpp1 equivalents. In this table, uppercase n
186
186
> Note: `as` unifies a variety of differently-named Cpp1 language and library casts and conversions under one syntax, and supports only the type-safe ones.
Casts that are not known to be type-safe at compile time must always be explicit.
192
192
193
-
To perform a numeric narrowing cast, such as `i32` to `i16` or `u32`, use `unsafe_narrow<To>(from)`. For example:
193
+
To perform a numeric narrowing cast, such as `i32` to `i16` or `u32`, use `unchecked_narrow<To>(from)`. Otherwise, if you must perform any other type-unsafe cast, use `unchecked_cast<To>(from)`. For example:
194
194
195
-
```cpp title="Unsafe narrowing and casts must be explicit" hl_lines="2 3 6 7"
195
+
```cpp title="Type-unsafe narrowing and casts must be explicit" hl_lines="2 3 6 7"
196
196
f: (i: i32, inout s: std::string) = {
197
197
// j := i as i16; // error, maybe-lossy narrowing
198
-
j := unsafe_narrow<i16>(i); // ok, 'unsafe' is explicit
198
+
j := unchecked_narrow<i16>(i); // ok, 'unchecked' is explicit
199
199
200
200
pv: *void = s&;
201
-
// pi := pv as *std::string; // error, unsafe cast
202
-
pi := unsafe_cast<*std::string>(pv); // ok, 'unsafe' is explicit
201
+
// pi := pv as *std::string; // error, type-unsafe cast
202
+
pi := unchecked_cast<*std::string>(pv); // ok, 'unchecked' is explicit
203
203
}
204
204
```
205
205
@@ -383,4 +383,3 @@ std::cout << "now x+2 is (x+2)$\n";
383
383
```
384
384
385
385
A string literal capture can include a `:suffix` where the suffix is a [standard C++ format specification](https://en.cppreference.com/w/cpp/utility/format/spec). For example, `#!cpp (x.price(): <10.2f)$` evaluates `x.price()` and converts the result to a string with 10-character width, 2 digits of precision, and left-justified.
Copy file name to clipboardExpand all lines: docs/cpp2/metafunctions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -337,7 +337,7 @@ Unlike C `#!cpp union`, this `@union` is safe to use because it always ensures o
337
337
338
338
Unlike C++11 `std::variant`, this `@union` is easier to use because its alternatives are anonymous, and safer to use because each union type is a distinct type. [^variant]
339
339
340
-
Each `@union` type has its own type-safe name, has clear and unambiguous named members, and safely encapsulates a discriminator to rule them all. Sure, it uses unsafe casts in the implementation, but they are fully encapsulated, where they can be tested once and be safe in all uses.
340
+
Each `@union` type has its own type-safe name, has clear and unambiguous named members, and safely encapsulates a discriminator to rule them all. It uses type-unsafe casts in the implementation, but they are fully encapsulated, where they can be tested once and be safe in all uses.
341
341
342
342
Because a `@union type` is still a `type`, it can naturally have other things normal types can have, such as template parameter lists and member functions:
Copy file name to clipboardExpand all lines: docs/welcome/overview.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,7 +25,7 @@ main: () = {
25
25
26
26
We can't make an improvement that large to C++ via gradual evolution to today's syntax, because some important changes would require changing the meaning of code written in today's syntax. For example, we can never change a language feature default in today's syntax, not even if the default creates a security vulnerability pitfall, because changing a default would break vast swathes of existing code. Having a distinct alternative syntax gives us a "bubble of new code" that doesn't exist today, and have:
27
27
28
-
-**Freedom to make any desired improvement, without breaking any of today's code.** Cpp2 is designed to take all the consensus C++ best-practices guidance we already teach, and make them the default when using "syntax 2." Examples: Writing unsafe type casts is just not possible in Cpp2 syntax; and Cpp2 can change language defaults to make them simpler and safer. You can always "break the glass" when needed to violate the guidance, but you have to opt out explicitly to write unsafe code, so if the program has a bug you can grep for those places to look at first. For details, see [Design note: unsafe code](https://github.com/hsutter/cppfront/wiki/Design-note%3A-Unsafe-code).
28
+
-**Freedom to make any desired improvement, without breaking any of today's code.** Cpp2 is designed to take all the consensus C++ best-practices guidance we already teach, and make them the default when using "syntax 2." Examples: Writing type-unsafe casts is just not possible in Cpp2 syntax; and Cpp2 can change language defaults to make them simpler and safer. You can always "break the glass" when needed to violate the guidance, but you have to opt out explicitly to write type-unsafe code (usually using the word `unchecked`), so if the program has a bug you can grep for those places to look at first. For details, see [Design note: unsafe code](https://github.com/hsutter/cppfront/wiki/Design-note%3A-Unsafe-code).
29
29
30
30
-**Perfect link compatibility always on, perfect source compatibility always available (but you pay for it only if you use it).** Any type/function/object/namespace written in either syntax is always still just a normal C++ type/function/object/namespace, so any code or library written in either Cpp2 or today's C++ syntax ("Cpp1" for short) can seamlessly call each other, with no wrapping/marshaling/thunking. You can write a "mixed" source file that has both Cpp2 and Cpp1 code and get perfect backward C++ source compatibility (even SFINAE and macros), or you can write a "pure" all-Cpp2 source file and write code in a 10x simpler syntax.
constexprautossize() const -> std::ptrdiff_t { return last - first; }
2553
2553
constexprautoempty() const -> bool { return first == last; }
2554
2554
@@ -2558,7 +2558,7 @@ class range
2558
2558
return first;
2559
2559
}
2560
2560
else {
2561
-
returnunsafe_narrow<T>(first);
2561
+
returnunchecked_narrow<T>(first);
2562
2562
}
2563
2563
}
2564
2564
@@ -2569,7 +2569,7 @@ class range
2569
2569
return --ret;
2570
2570
}
2571
2571
else {
2572
-
auto ret = unsafe_narrow<T>(last);
2572
+
auto ret = unchecked_narrow<T>(last);
2573
2573
return --ret;
2574
2574
}
2575
2575
}
@@ -2581,7 +2581,7 @@ class range
2581
2581
return first + i;
2582
2582
}
2583
2583
else {
2584
-
returnunsafe_narrow<T>(first + i);
2584
+
returnunchecked_narrow<T>(first + i);
2585
2585
}
2586
2586
}
2587
2587
else {
@@ -2745,7 +2745,7 @@ CPP2_FORCE_INLINE constexpr auto cmp_mixed_signedness_check() -> void
2745
2745
// static_assert to reject the comparison is the right way to go.
2746
2746
static_assert(
2747
2747
program_violates_type_safety_guarantee<T, U>,
2748
-
"mixed signed/unsigned comparison is unsafe - prefer using .ssize() instead of .size(), consider using std::cmp_less instead, or consider explicitly casting one of the values to change signedness by using 'as' or 'cpp2::unsafe_narrow'"
2748
+
"mixed signed/unsigned comparison is unsafe - prefer using .ssize() instead of .size(), consider using std::cmp_less instead, or consider explicitly casting one of the values to change signedness by using 'as' or 'cpp2::unchecked_narrow'"
2749
2749
);
2750
2750
}
2751
2751
}
@@ -2842,14 +2842,14 @@ constexpr auto as_( auto&& x ) -> decltype(auto)
"'as' does not allow unsafe possibly-lossy narrowing conversions - if you're sure you want this, use 'unsafe_narrow<T>' to explicitly force the conversion and possibly lose information"
2845
+
"'as' does not allow unsafe possibly-lossy narrowing conversions - if you're sure you want this, use 'unchecked_narrow<T>' to explicitly force the conversion and possibly lose information"
"'as' does not allow unsafe possibly-lossy narrowing conversions - if you're sure you want this, use `unsafe_narrow<T>()` to explicitly force the conversion and possibly lose information"
2872
+
"'as' does not allow unsafe possibly-lossy narrowing conversions - if you're sure you want this, use `unchecked_narrow<T>()` to explicitly force the conversion and possibly lose information"
0 commit comments