Thread overview | |||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 03, 2019 Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
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. |
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | 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.
|
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ag0aep6g | 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.
|
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ag0aep6g | 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; }
----
|
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | 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.
|
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ag0aep6g | 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.
|
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rubn | 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.
|
February 03, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ag0aep6g | On 2/3/2019 4:31 PM, ag0aep6g wrote: > [...] https://issues.dlang.org/show_bug.cgi?id=19645 |
February 03, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Luís Marques | On 2/3/2019 3:48 PM, Luís Marques wrote: > [...] https://issues.dlang.org/show_bug.cgi?id=19646 |
February 04, 2019 Re: Both safe and wrong? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
Copyright © 1999-2021 by the D Language Foundation