On 3/31/2020 2:26 PM, Joseph Rushton Wakeling wrote:
> [...]

Thanks for the great read.

On 4/1/2020 5:40 AM, Joseph Rushton Wakeling wrote:
> Before we derail the discussion thread any more, maybe I ought to have a chat with a few former colleagues just to refresh memories, and write this up as a blog post ...

It'd make a great blog post. Please do!

On Wednesday, 1 April 2020 at 21:32:29 UTC, Walter Bright wrote:
> On 3/31/2020 2:12 PM, Arine wrote:
>> With the current implementation and proposal of @live, it is effectively the equivalent of comparing a pair of scissors to a lawn mower. To be comparable to something like Rust would require an entire language rewrite from the ground up. Even though there are already significant breaking changes, they aren't sufficient and I don't imagine breaking everything completely is on the table.
>
> I've encountered such opinions my entire career. Fortunately, I never pay attention to them.

That's why Rust, a completely new language that doesn't follow similar syntax of another language and requires developers to completely rewrite their code is doing much much better than D? Gotcha.

https://github.com/dlang/dlang.org/commit/9bede81001c1b1486e749dbaf3ee81087476c9c6#diff-f40612a5a1a025f217fe29cb0df257ddR56

> The future of programming will be multicore, multithreaded. Languages that
> make it easy to program them will supplant languages that don't.
> Transitive const is key to bringing D into this paradigm. The surge in
> use of Haskell and Erlang is evidence of this coming trend (the killer
> feature of those languages is they make it easy to do multiprogramming).

This all sounds so familiar.

Here you have one of D's most avoided features that was the key to bringing D into the "future".

People that are gravitating towards Rust would not deem the implementation of @live suitable.

But ya'know, thank goodness you just ignored everyone else's opinions and continued in your spearheaded stubborn ways.

I'll ask again since you didn't reply last time. Have you ever written Rust? Have you ever used Rust? From your implementation of @live, I feel as though you haven't.

On 3/27/2020 2:40 AM, Mathias Lang wrote:
> Changing the default makes it "easier" to deal with `@safe` by making it harder to deal with `@system`. How is that an improvement?

The idea is that @system code should be relatively rare - much rarer than @safe code.

Generally speaking, the common case should be the default one.

On 3/27/2020 5:32 AM, aliak wrote:
> So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required?

No. Without an explicit annotation, it will be the default (@safe).

On Friday, 3 April 2020 at 09:50:39 UTC, Walter Bright wrote:
> On 3/27/2020 5:32 AM, aliak wrote:
>> So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required?
>
> No. Without an explicit annotation, it will be the default (@safe).

And absolutely no one else thing it's a good idea, because it's essentially slapping `@trusted` on all `extern(C)` functions.

On Friday, 3 April 2020 at 10:15:35 UTC, Mathias LANG wrote:
> On Friday, 3 April 2020 at 09:50:39 UTC, Walter Bright wrote:
>> On 3/27/2020 5:32 AM, aliak wrote:
>>> So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required?
>>
>> No. Without an explicit annotation, it will be the default (@safe).
>
> And absolutely no one else thing it's a good idea, because it's essentially slapping `@trusted` on all `extern(C)` functions.

I think I agree. I'd sooner have no default at all on functions without implementation (i.e. you have to explicitly say @system).

As I just said over in this other thread:

https://forum.dlang.org/post/jipdihpufuslnfayhakh@forum.dlang.org

if we get DIP 1032 done correctly, with the obvious consequences of it done, it makes this DIP 1028 a totally unnecessary major breaking change.

On 04/04/2020 12:27 AM, John Colvin wrote:
> On Friday, 3 April 2020 at 10:15:35 UTC, Mathias LANG wrote:
>> On Friday, 3 April 2020 at 09:50:39 UTC, Walter Bright wrote:
>>> On 3/27/2020 5:32 AM, aliak wrote:
>>>> So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required?
>>>
>>> No. Without an explicit annotation, it will be the default (@safe).
>>
>> And absolutely no one else thing it's a good idea, because it's essentially slapping `@trusted` on all `extern(C)` functions.
> 
> I think I agree. I'd sooner have no default at all on functions without implementation (i.e. you have to explicitly say @system).

Unless the compiler has checked the body for @safe, it cannot be assumed to be @safe. As that breaks its guarantees.

So I am on the side of, without body, default = @system.

On 4/3/20 10:39 AM, rikki cattermole wrote:
> On 04/04/2020 12:27 AM, John Colvin wrote:
>> On Friday, 3 April 2020 at 10:15:35 UTC, Mathias LANG wrote:
>>> On Friday, 3 April 2020 at 09:50:39 UTC, Walter Bright wrote:
>>>> On 3/27/2020 5:32 AM, aliak wrote:
>>>>> So my understanding is if extern (C) is applied on a function declaration, then an annotation is explicitly required?
>>>>
>>>> No. Without an explicit annotation, it will be the default (@safe).
>>>
>>> And absolutely no one else thing it's a good idea, because it's essentially slapping `@trusted` on all `extern(C)` functions.
>>
>> I think I agree. I'd sooner have no default at all on functions without implementation (i.e. you have to explicitly say @system).
> 
> Unless the compiler has checked the body for @safe, it cannot be assumed to be @safe. As that breaks its guarantees.
> 
> So I am on the side of, without body, default = @system.

For extern(D) functions, the mangling takes care of the problem. I would say everything that doesn't mangle @safe-ty into the name, assume system (breaks less code but inconsistent/less clear) OR error (requires annotation, so breaks code, but is clearer).

Basically, this only comes into play for .di files.

-Steve