Consider this code:
https://run.dlang.io/is/aw09pD

import std.stdio;

@safe:

const x = 42;
int* y = cast(int*) &x;

void main()
{
    *y = 7;
    writeln(x); // prints 42
}

I'm probably too out of touch of how the safe type system should work, but this seems inconsistent. I would expect *either*:

1) Overriding x's const is unsafe and undefined behavior. The cast inside a safe block should cause an error. The 42 is fine.

2) As we promised the type system, we didn't modify the 42 through a const view of that value (x), instead we used a mutable view (y). The cast is fine. It should print 7 instead.

But I guess I'm wrong? Please clarify.

On 04.02.19 00:48, Luís Marques wrote:
> import std.stdio;
> 
> @safe:
> 
> const x = 42;
> int* y = cast(int*) &x;
> 
> void main()
> {
>      *y = 7;
>      writeln(x); // prints 42
> }
> 
> I'm probably too out of touch of how the safe type system should work, but this seems inconsistent. I would expect *either*:
> 
> 1) Overriding x's const is unsafe and undefined behavior. The cast inside a safe block should cause an error. The 42 is fine.
> 
> 2) As we promised the type system, we didn't modify the 42 through a const view of that value (x), instead we used a mutable view (y). The cast is fine. It should print 7 instead.

The thing here is that the @safe attribute only applies to functions. `int* y = cast(int*) &x;` is not a function declaration, so `@safe:` has no effect on it.

All code that's not in a function is @system, always. There is no way to mark it as @safe.

On Monday, 4 February 2019 at 00:18:48 UTC, ag0aep6g wrote:
> The thing here is that the @safe attribute only applies to functions. `int* y = cast(int*) &x;` is not a function declaration, so `@safe:` has no effect on it.

Gotcha. It's disappointing that there is no way to mark an entire module as safe. Also seems a bit inconsistent with other attributes marked with the "attribute:" syntax, which apply more broadly.

On 04.02.19 01:18, ag0aep6g wrote:
> The thing here is that the @safe attribute only applies to functions. `int* y = cast(int*) &x;` is not a function declaration, so `@safe:` has no effect on it.
> 
> All code that's not in a function is @system, always. There is no way to mark it as @safe.

Maybe even more peculiar than globals, you also can't mark parameter default values as @safe:

----
import std.stdio;

@safe:

immutable x = 42;

void main()
{
    *f() = 7;
    writeln(x); // 42
    writeln(*&x); // 7
}

int* f(int* y = cast(int*) &x) { return y; }
----

On Monday, 4 February 2019 at 00:29:04 UTC, Luís Marques wrote:
> On Monday, 4 February 2019 at 00:18:48 UTC, ag0aep6g wrote:
>> The thing here is that the @safe attribute only applies to functions. `int* y = cast(int*) &x;` is not a function declaration, so `@safe:` has no effect on it.
>
> Gotcha. It's disappointing that there is no way to mark an entire module as safe. Also seems a bit inconsistent with other attributes marked with the "attribute:" syntax, which apply more broadly.

Walter is extremely against the idea of

    @safe module std.stdio;

It's kind of ironic that you can't have @safe code that's not in a function. Kind of seems like a gigantic hole in creating a safe language.

On Monday, 4 February 2019 at 00:31:36 UTC, ag0aep6g wrote:
> Maybe even more peculiar than globals, you also can't mark parameter default values as @safe:

Yup, clearly @safe's scope could be expanded. I don't know how problematic that would be with D's current design...? I use @safe so little (because most of the times I've tried to use it I ran into annoying limitations) I'm quite out of touch with its details. In fact, that's how this whole thread started. I was thinking about some possible changes to the type system and it wasn't quite clear to me how that interacted with @safe, because I don't use it enough.

On Monday, 4 February 2019 at 00:35:43 UTC, Rubn wrote:
> It's kind of ironic that you can't have @safe code that's not in a function. Kind of seems like a gigantic hole in creating a safe language.

Right. As CTFE illustrates, a variable's initialization expression is a kind of compile-time code. See the fine line between constant folding and CTFE, etc. So, not being inside a function declaration is not a particularly useful distinction, from the user's point of view. In fact, that's what I was thinking about when I started this thread: some possible changes to the way that expressions are typed, and how that interacts with @safe.

On 2/3/2019 4:31 PM, ag0aep6g wrote:
> [...]
https://issues.dlang.org/show_bug.cgi?id=19645

On 2/3/2019 3:48 PM, Luís Marques wrote:
> [...]
https://issues.dlang.org/show_bug.cgi?id=19646

On Monday, 4 February 2019 at 01:39:20 UTC, Walter Bright wrote:
> On 2/3/2019 3:48 PM, Luís Marques wrote:
>> [...]
> https://issues.dlang.org/show_bug.cgi?id=19646

Amazing