On 23.05.20 21:46, Arafel wrote:
> Now it has to be clearly explained that you should check for @trusted code AND unmarked external C functions.

... and @system static constructors and `--boundscheck=off` and initializers of globals

On 5/23/2020 4:26 AM, Faux Amis wrote:
> Just a suggestion, but sometimes matters are best discussed over audio/video. Would having a public teams/zoom/.. meeting be helpful?
> 
> I would definitely listen/watch; even if I were muted and could only chat maybe.

You're right, and that is the whole purpose behind DConf. It's amazing how our differences melt away when discussing with a beer in hand :-)

On 24/5/20 0:02, ag0aep6g wrote:
> 
> ... and @system static constructors and `--boundscheck=off` and initializers of globals

Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe code?

I would find concerning that any @system code is allowed, but I guess initializers of globals should be ok as long as they are @safe themselves?

On 24.05.20 00:17, Arafel wrote:
> On 24/5/20 0:02, ag0aep6g wrote:
>>
>> ... and @system static constructors and `--boundscheck=off` and initializers of globals
> 
> Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe code?

Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, they can be explicitly marked @system. Either way, they don't show up when you only look for "@trusted".

> I would find concerning that any @system code is allowed, but I guess initializers of globals should be ok as long as they are @safe themselves?

As long as they're @safe, sure. But they can also be @system.

An example:
----
const int x = 42;
const int y = 43;

void main() @safe
{
    import std.stdio;
    writeln(x, " ", y); /* Prints "42 43" as expected. */
    auto px = &x;
    auto py = &y;
    writeln(*px, " ", *py); /* Prints "13 14". Wat? */
}

int* p = cast(int*) &x;
static this() @system { *p = 13; *++p = 14; }
----

On 23.05.20 17:07, Andrei Alexandrescu wrote:
> A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead.

I can only read that as you calling larsivi not "good enough to lead a successful fork" and not "wise enough to work on the D language instead".

Walter says: "Belittling [others] [...] is unprofessional behavior."

He was refering to other people on the forum, of course. But I would expand that to authors of other projects as well, particularly ones that are (even) smaller than D. Punching down is not cool.

On 24/5/20 0:38, ag0aep6g wrote:
> On 24.05.20 00:17, Arafel wrote:
>> On 24/5/20 0:02, ag0aep6g wrote:
>>>
>>> ... and @system static constructors and `--boundscheck=off` and initializers of globals
>>
>> Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe code?
> 
> Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, they can be explicitly marked @system. Either way, they don't show up when you only look for "@trusted".
> 
>> I would find concerning that any @system code is allowed, but I guess initializers of globals should be ok as long as they are @safe themselves?
> 
> As long as they're @safe, sure. But they can also be @system.
> 
> An example:
> ----
> const int x = 42;
> const int y = 43;
> 
> void main() @safe
> {
>      import std.stdio;
>      writeln(x, " ", y); /* Prints "42 43" as expected. */
>      auto px = &x;
>      auto py = &y;
>      writeln(*px, " ", *py); /* Prints "13 14". Wat? */
> }
> 
> int* p = cast(int*) &x;
> static this() @system { *p = 13; *++p = 14; }
> ----
> 

I find this... disturbing... what is worse, it also happens with `immutable`.

Then there should most definitely be a list of features to look (in addition to `@trusted`) if you want to make sure your `@safe` code is actually safe.

On 5/23/20 6:49 PM, ag0aep6g wrote:
> On 23.05.20 17:07, Andrei Alexandrescu wrote:
>> A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead.
> 
> I can only read that as you calling larsivi not "good enough to lead a successful fork" and not "wise enough to work on the D language instead".
> 
> Walter says: "Belittling [others] [...] is unprofessional behavior."
> 
> He was refering to other people on the forum, of course. But I would expand that to authors of other projects as well, particularly ones that are (even) smaller than D. Punching down is not cool.

The point is on the other side - the barrier is very high. Carrying a programming language design and implementation is an extremely difficult task.

On 5/22/2020 10:25 AM, Timon Gehr wrote:
>> With the o/b system `free` might actually work out OK....
> 
> free(new int);

I did mention in the documentation that when using different memory allocators, mixing them up will not be detected. You'd have to declare the allocators using specific pointer types, rather than void*.

On Saturday, 23 May 2020 at 15:07:16 UTC, Andrei Alexandrescu wrote:
> On 5/21/20 7:49 PM, Bruce Carneal wrote:
>> On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote:
>>> On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote:
>>>> Why we can't we have a technical board where the community can vote in experts and potentially companies could even buy a seat for $$$ which would mean a lot more for them than the current very vague sponsorship options.
>>>
>>> ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless.
>> 
>> As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see.  If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down".
>> 
>> Atila, what's your take on all this?  Is it fork time?
>
> A fork does exist. As expected it went nowhere. https://bitbucket.org/larsivi/amber/wiki/Home. There is a paradox about forking the language - anyone good enough to lead a successful fork would also be wise enough to work on the D language instead.

Arguably they would then be wise enough to stay away from D (and have).

> His strength comes with equally unique ability to explain and debate, which makes many of the discussions in forums very frustrating.

It is unique that's for sure. That's a good way to put it without being rude.

On Saturday, 23 May 2020 at 22:38:58 UTC, ag0aep6g wrote:
> On 24.05.20 00:17, Arafel wrote:
>> On 24/5/20 0:02, ag0aep6g wrote:
>>>
>>> ... and @system static constructors and `--boundscheck=off` and initializers of globals
>> 
>> Other than `--boundscheck=off`, that is presumably actively chosen by the user (as is @trust), would the others be allowed without `@trusted` in otherwise 100% @safe code?
>
> Yup. Today they can be unmarked, defaulting to @system. With DIP 1028, they can be explicitly marked @system. Either way, they don't show up when you only look for "@trusted".
>
>> I would find concerning that any @system code is allowed, but I guess initializers of globals should be ok as long as they are @safe themselves?
>
> As long as they're @safe, sure. But they can also be @system.
>
> An example:
> ----
> const int x = 42;
> const int y = 43;
>
> void main() @safe
> {
>     import std.stdio;
>     writeln(x, " ", y); /* Prints "42 43" as expected. */
>     auto px = &x;
>     auto py = &y;
>     writeln(*px, " ", *py); /* Prints "13 14". Wat? */
> }
>
> int* p = cast(int*) &x;
> static this() @system { *p = 13; *++p = 14; }
> ----

That works even if you make the static this() @safe, and remove the pointer incrementation.

You'd have to make the p initialization @safe.

    @safe:
        int* p = cast(int*) &x; // error

But note this doesn't work:

    @safe int* p = cast(int*) &x; // compiles

Having the default become @safe will help detect this, as I don't imagine that is a whole lot of usage of @safe: to begin with.