DIP 1028---Make @safe the Default---Community Review Round 1
Walter Bright
newshound2 at digitalmars.com
Wed Jan 15 18:08:33 UTC 2020
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
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.
> However, I wonder how languages with such blocks deal
> with problems such as these:
>
> @safe void someFunction()
> {
> int[4] data;
> // Lot's of code
> @trusted
> {
> data.ptr[3] = 42;
> }
> }
>
> Now someone changes data to int[2]:
>
> @safe void someFunction()
> {
> int[2] data;
> // Lot's of code
> @trusted
> {
> data.ptr[3] = 42;
> }
> }
>
> So by modifying @safe code only, you introduced a memory safety issue.
> The interface of a @trusted function however is more strictly defined:
>
> @trusted function set(ref int[4] data)
> {
> data.ptr[3] = 42;
> }
>
> It's not possible to break the set function in @safe code. You could
> probably argue that the trusted block in someFunction should have covered
> the int[2] data definition and that you can also write @trusted functions
> which do not properly check / enforce their parameters and can be broken
> from @safe code.
Exactly right.
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.
More information about the Digitalmars-d
mailing list