January 07, 2020
On 1/6/2020 3:59 PM, Manu wrote:
> Well all feedback I've received is that it fails at the rule of least
> surprise. Definitely not intuitive what it means.

I'm frankly surprised at this. Yours is literally the first complaint about using `system` in 10 years that has come to my ears.

Also, a safe/unsafe dichotomy can make sense. But a safe/trusted/unsafe makes less sense, like a 3 state boolean.

> I think it may be possible to see and consider the situation
> differently when looking from a safe-by-default perspective; today
> where 'system' is default, you wouldn't want to advertise the language
> as "unsafe by default"... but if safe is default, than 'unsafe' feels
> a lot more reasonable for the exceptions. I reckon the change in
> default may change your judgement that you describe above.

`static` in C makes no particular sense, but people are so used to it that they imagine it makes perfect sense :-)

Nobody expects to be able to implement a storage allocator in code that is provably correct. Nobody expects the implementation of atomic shared operations to to be provably. People have historically called such underpinnings "system" code (long before there was a notion of "unsafe"), where the dirty but necessary work happens. Steamships had white-glove service to the passengers, and the greasy dirty work went on in the "system" under the decks to support it all.

Whether "system" is intuitive or not is how you frame it. It's a perfect moniker. It is not "unsafe", it just means the compiler cannot prove it safe.
January 08, 2020
On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> On 1/6/2020 3:59 PM, Manu wrote:
>> Well all feedback I've received is that it fails at the rule of least
>> surprise. Definitely not intuitive what it means.
>
> I'm frankly surprised at this. Yours is literally the first complaint about using `system` in 10 years that has come to my ears.

I was confused by the naming too at first.
January 08, 2020
On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 wrote:
> On Friday, 3 January 2020 at 22:36:17 UTC, Alex wrote:
>> [...]
>> Not sure, if this fits here. But if I add ´´´@safe:´´´ at the beginning of the module, the library https://code.dlang.org/packages/vebtree does not compile any more.
>
> you can't just slap `@safe:` on because all the libraries and stuff you depend on which wasn't marked @safe is still gonna stay @system and thus disallow your calls. Instead you need to use the compiler with the @safe by default PR.
>
> I have done this for all dub packages now so everyone can review what this change actually does to their packages:
>
> https://i.webfreak.org/safe-test/index.html
>
> It seems that your vebtree package compiles fine, however that is not to say for the rest of dub. Currently a lot of issues are caused by phobos' std.bitmanip.bitfields. So a lot of these errors are certainly fixable, but currently it doesn't look good in terms of support. (Tested using phobos v2.089.1-198-gbb8ba28bf)

When providing results, it is best to provide your methodology alongside them so people can reproduce. So is there somewhere public I can find your build scripts ?

I myself gave a try to the switch, but I didn't expect *anything* to work, as I was sure druntime/Phobos would not compile with '-preview=safedefault', and as I mentioned already, we'll hit linker error if we don't compile them with '-preview=safedefault'.

The results I got were as I expected (https://github.com/dlang/dmd/pull/10709#issuecomment-571899986), which seems to be at odds with what you're seeing.
January 08, 2020
On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> On 1/6/2020 3:59 PM, Manu wrote:
>> Well all feedback I've received is that it fails at the rule of least
>> surprise. Definitely not intuitive what it means.
>
> I'm frankly surprised at this. Yours is literally the first complaint about using `system` in 10 years that has come to my ears.
>
> Also, a safe/unsafe dichotomy can make sense. But a safe/trusted/unsafe makes less sense, like a 3 state boolean.

@trusted doesn't really make sense. It is pretty much @system that @safe can call. It's actually kind of bad as how easily it can be misused. @trusted: comes to mind. You can have @trusted destructors. So when you are reading @safe code you can't easily tell where potentially @unsafe code is located. As the @trusted is applied to the function, not at the call site (like Rust/C#).

If we are going to make @safe the default we don't really need @safe keyword, or @system or @trusted. It's make sense to get rid of all 3 of them and just add @unsafe. If you are going to do it, might as well do it right the first time.


@safe void potentialProblem() {
    A a;

    where();
    is();
    the();
    potential();
    problem(here ? maybe() : maybeNot());
}


// safe by default //
void potentialProblem() {
    A a;

    where();
    is();
    unsafe {
        the(); // easily identifiable
    }
    potential();
    problem(here ? maybe() : maybeNot());
}


>> I think it may be possible to see and consider the situation
>> differently when looking from a safe-by-default perspective; today
>> where 'system' is default, you wouldn't want to advertise the language
>> as "unsafe by default"... but if safe is default, than 'unsafe' feels
>> a lot more reasonable for the exceptions. I reckon the change in
>> default may change your judgement that you describe above.
>
> `static` in C makes no particular sense, but people are so used to it that they imagine it makes perfect sense :-)
>
> Nobody expects to be able to implement a storage allocator in code that is provably correct. Nobody expects the implementation of atomic shared operations to to be provably. People have historically called such underpinnings "system" code (long before there was a notion of "unsafe"), where the dirty but necessary work happens. Steamships had white-glove service to the passengers, and the greasy dirty work went on in the "system" under the decks to support it all.
>
> Whether "system" is intuitive or not is how you frame it. It's a perfect moniker. It is not "unsafe", it just means the compiler cannot prove it safe.

If you can't prove it is safe, logic dictates it should then be identified as unsafe.

January 08, 2020
On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> Also, a safe/unsafe dichotomy can make sense. But a safe/trusted/unsafe makes less sense, like a 3 state boolean.
>
Which it defacto is. we should get rid of @trusted (at function level) and replace it by @trusted expressions.
But whether the remaining @system is kept or renamed to @unsafe really doesn't matter, I think.

January 08, 2020
On Wednesday, 8 January 2020 at 05:47:15 UTC, Mathias Lang wrote:
> On Saturday, 4 January 2020 at 10:22:34 UTC, WebFreak001 wrote:
>> [...]
>
> When providing results, it is best to provide your methodology alongside them so people can reproduce. So is there somewhere public I can find your build scripts ?
>
> I myself gave a try to the switch, but I didn't expect *anything* to work, as I was sure druntime/Phobos would not compile with '-preview=safedefault', and as I mentioned already, we'll hit linker error if we don't compile them with '-preview=safedefault'.
>
> The results I got were as I expected (https://github.com/dlang/dmd/pull/10709#issuecomment-571899986), which seems to be at odds with what you're seeing.

I didn't compile druntime or phobos with the -preview=safedefault flag, only the dub packages.

The command for building the dub packages is at the very top.

dmd-safe-wrapper is a simple .sh file like this:
/opt/dmd-safe/dmd/generated/linux/release/64/dmd -preview=safedefault "$@"

see the other thread in general for replies pls
January 08, 2020
On Tuesday, 7 January 2020 at 06:24:11 UTC, Max Samukha wrote:
> On Monday, 6 January 2020 at 23:59:28 UTC, Manu wrote:
>
>> Well all feedback I've received is that it fails at the rule of least
>> surprise.
>
> The feedback is incomplete. I have disliked "unsafe" since C# and know a few people who do as well. One of C# creators even admitted publicly that "unsafe" was a misnomer.

I like "@system" as a name.
I'll live almost entirely in @system since pointers seems to perform well (not the least is that you are guaranteed no bounds check).

@system code isn't necessarily broken, and I don't necessarily want to read "unsafe" all day.
January 08, 2020
On Wed, Jan 8, 2020 at 12:50 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 1/6/2020 3:59 PM, Manu wrote:
> > Well all feedback I've received is that it fails at the rule of least surprise. Definitely not intuitive what it means.
>
> I'm frankly surprised at this. Yours is literally the first complaint about using `system` in 10 years that has come to my ears.

It's the kind of thing that people wouldn't bother complaining about,
because it has no material affect on their ability to get their job
done, it's just weird.
I mean, I've thought this the whole time, and I've never said it here.
The only reason that I feel it was worth raising the topic, is because
this is the one single moment that it would be possible to make this
change... so it seems worth the thought.

> Also, a safe/unsafe dichotomy can make sense. But a safe/trusted/unsafe makes less sense, like a 3 state boolean.

I don't think it makes any less sense. It seems reasonable that safe code can't call unsafe code, unless we `trust` it.

> > I think it may be possible to see and consider the situation differently when looking from a safe-by-default perspective; today where 'system' is default, you wouldn't want to advertise the language as "unsafe by default"... but if safe is default, than 'unsafe' feels a lot more reasonable for the exceptions. I reckon the change in default may change your judgement that you describe above.
>
> `static` in C makes no particular sense, but people are so used to it that they imagine it makes perfect sense :-)

We're not asking people to get on board with nonsense decisions that C
made 50 years ago, we're asking new users to feel that D is natural
and desirable.
My experience is this (with no exceptions): there is a finite number
of 'weird shit' experiences that a new user can digest before they
stop and lose interest, and there are lots of ways we burn through
that budget. At some point, we blow the threshold and they go away.
Every single person I've introduced to D has followed this pattern,
sadly.
Every... single... one.

This is indeed a very minor one, but these sorts of weird perceptions still consume some of that balance. In this case, I see no reason for anything other than a completely intuitive and expected language, and they would be comfortable, accept that D makes perfect sense on this matter, and the budget remains for other more important stuff which certainly exists.

> Nobody expects to be able to implement a storage allocator in code that is provably correct. Nobody expects the implementation of atomic shared operations to to be provably. People have historically called such underpinnings "system" code (long before there was a notion of "unsafe"), where the dirty but necessary work happens. Steamships had white-glove service to the passengers, and the greasy dirty work went on in the "system" under the decks to support it all.
>
> Whether "system" is intuitive or not is how you frame it. It's a perfect moniker. It is not "unsafe", it just means the compiler cannot prove it safe.

Whatever you reckon. I was just offering that there's an opportunity here.
January 08, 2020
On Wed, Jan 8, 2020 at 5:15 PM Arine via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 8 January 2020 at 02:48:19 UTC, Walter Bright wrote:
> > On 1/6/2020 3:59 PM, Manu wrote:
> >> Well all feedback I've received is that it fails at the rule
> >> of least
> >> surprise. Definitely not intuitive what it means.
> >
> > I'm frankly surprised at this. Yours is literally the first complaint about using `system` in 10 years that has come to my ears.
> >
> > Also, a safe/unsafe dichotomy can make sense. But a safe/trusted/unsafe makes less sense, like a 3 state boolean.
>
> @trusted doesn't really make sense. It is pretty much @system that @safe can call. It's actually kind of bad as how easily it can be misused. @trusted: comes to mind. You can have @trusted destructors. So when you are reading @safe code you can't easily tell where potentially @unsafe code is located. As the @trusted is applied to the function, not at the call site (like Rust/C#).
>
> If we are going to make @safe the default we don't really need @safe keyword, or @system or @trusted. It's make sense to get rid of all 3 of them and just add @unsafe. If you are going to do it, might as well do it right the first time.
>
>
> @safe void potentialProblem() {
>      A a;
>
>      where();
>      is();
>      the();
>      potential();
>      problem(here ? maybe() : maybeNot());
> }
>
>
> // safe by default //
> void potentialProblem() {
>      A a;
>
>      where();
>      is();
>      unsafe {
>          the(); // easily identifiable
>      }
>      potential();
>      problem(here ? maybe() : maybeNot());
> }

Actually, this is a really good point! I've had this thought many times.
January 08, 2020
On Wednesday, 8 January 2020 at 07:10:03 UTC, Arine wrote:
>
> If we are going to make @safe the default we don't really need @safe keyword, or @system or @trusted. It's make sense to get rid of all 3 of them and just add @unsafe. If you are going to do it, might as well do it right the first time.


Removing `@safe` as a keyword removes the ability to force templates to be `@safe`.