DIP 1028---Make @safe the Default---Community Review Round 1
Timon Gehr
timon.gehr at gmx.ch
Wed Jan 15 18:46:20 UTC 2020
On 15.01.20 19:08, Walter Bright wrote:
> On 1/9/2020 10:47 AM, Johannes Pfau wrote:
>> I agree that the lambda thing is an ugly hack and proper trusted blocks
>> would be better.
>
> It's intended to be that way. Bad language design is where the simple,
> straightforward code is considered bad form, for example, in C++:
>
> void foo(int array[]) // bad, boo hiss
>
> #include <vector>
> void foo(std::vector<int> array); // good, you get a gold star
> ...
Or perhaps
#include <vector>
void foo(std::vector<int> const &array);
> Besides, most of the ugliness I've seen comes from excessively trying to
> reduce the number of characters. Making it a regular nested function
> with a name makes it nice.
> ...
Maybe it looks nice. A @trusted nested function that depends on
enclosing @safe code to ensure memory safety is however still not valid.
> ...
>
> Let's make it look nicer:
>
> @safe void someFunction()
> {
> int[4] data;
> // Lot's of code
>
> @trusted void set() { data.ptr[3] = 42; }
>
> set();
> }
>
>
>> But still, it seems like applying trusted/safe at function level provides
>> stronger guarantees.
>
> It also makes it easier for both the compiler and user to reason about.
> The user doesn't need to bother wondering/worrying if the compiler will
> detect breaking the @trusted code by changing the @safe code.
It will not. The "nice" version is bad.
More information about the Digitalmars-d
mailing list