On Wednesday, 27 May 2020 at 21:01:51 UTC, Steven Schveighoffer wrote:
> Perhaps instead of making these things the default, we instead made *inference* the default.

Thats a brilliant idea, however the issue of extern still remains with the additional complication of mangling due to attributes and also separate compilation/.di files.

Separate compilation may be a lot slower if inference must be done for function bodies.
For anyone that experiences significant slowdowns as a result I see no harm in a switch to disable it.

On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:
> Thats a brilliant idea, however the issue of extern still remains with the additional complication of mangling due to attributes and also separate compilation/.di files.

extern ones (including probably abstract/interface methods) require an annotation, otherwise it is inferred.

Then you can explicitly put a thing on if you want a guarantee of it (as a user) or to provide a guarantee of it (as a lib designer / interface publisher).

It really does lead to everyone wins... and this pattern can be extended to other functions as well. And we have precedent with templates.

> Separate compilation may be a lot slower if inference must be done for function bodies.

Extremely unlikely - it already does those checks to confirm the annotation anyway!

On Thursday, 28 May 2020 at 00:59:30 UTC, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:
>> Thats a brilliant idea, however the issue of extern still remains with the additional complication of mangling due to attributes and also separate compilation/.di files.
>
> extern ones (including probably abstract/interface methods) require an annotation, otherwise it is inferred.

I meant as in they still require  default of _something_, and given recent times that contention is unlikely to go away. I hadn't though about inheritance at all, thats tricky.

> Extremely unlikely - it already does those checks to confirm the annotation anyway!

Ah, I didn't know that! All the more reason for all at once (or at least package at a time)!

On 5/27/20 8:59 PM, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 00:51:52 UTC, Nicholas Wilson wrote:

>> Separate compilation may be a lot slower if inference must be done for function bodies.
> 
> Extremely unlikely - it already does those checks to confirm the annotation anyway!

This isn't something I thought of. I am surprised if the compiler semantically analyzes only-imported functions. In fact, I'm almost sure this doesn't happen (based on D's track record with unittests).

But in practice much of D is actually templates already. I doubt this would have a tremendous impact.

In any case, this COULD be mitigated via some sort of intermediate form, or .di files.

-Steve

On 5/27/20 8:31 PM, Jonathan M Davis wrote:
> On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
>> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
>>> Based on some of Walter's comments, it also sounds like he
>>> intends to make nothrow the default in another DIP, which is
>>> also a terrible idea. I'm increasingly worried about the future
>>> of D with some of where these DIPs are going.
>>>
>>> - Jonathan M Davis
>>
>> What's wrong with nothrow by default? Probably 97% of code
>> doesn't need to throw exceptions.
> 
> If anything, I would say the opposite.

It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue.

-Steve

On Thursday, 28 May 2020 at 01:20:31 UTC, Steven Schveighoffer wrote:
> This isn't something I thought of. I am surprised if the compiler semantically analyzes only-imported functions. In fact, I'm almost sure this doesn't happen (based on D's track record with unittests).

aaaargh, I'm sorry, you're right. I forgot I habitually use -i now which brings it in for full analysis.

It only does this for auto functions and templates in imported modules right now.

On 5/27/20 9:32 PM, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 01:20:31 UTC, Steven Schveighoffer wrote:
>> This isn't something I thought of. I am surprised if the compiler semantically analyzes only-imported functions. In fact, I'm almost sure this doesn't happen (based on D's track record with unittests).
> 
> aaaargh, I'm sorry, you're right. I forgot I habitually use -i now which brings it in for full analysis.
> 
> It only does this for auto functions and templates in imported modules right now.

Even so, things like DUB could automatically build .di files if this was an issue.

-Steve

On Wednesday, 27 May 2020 at 11:37:17 UTC, Andrei Alexandrescu wrote:
(...)
> If this is greenwashing, then DIP 1028 is doing it.

Using the greenwashing phrase against Walter's case for DIP 1028 is a good rhetoric, but a weak argument and does little good I believe to further this conversation.

At least you did bring a definition into the mix, almost everyone else seems to have misunderstood what greenwashing even means!

It's exactly Walter's argument that *not* marking external declarations as safe by the compiler will lead to greenwashing by humans in practice, some programmer (not compiler!) putting safe declaration there to shut up the compiler. This act cannot be easily distinguished from careful analysis, thus misleading others about the memory safety of the codebase.

The compiler simply follows the rules without agenda, but a human has more complex intentions. Thus, there is a very big difference is something has been 'calculated' or 'created'. And anyone reading the code who is up to date about the rules will make that difference. This is a matter of coder psychology, not language lawyers. At least this is how I understand Walters argument.

The way that DIP 1028 would mislead coders about memory safety of the codebase is quite different. I think it boils down to 2 kinds of deception:

1. @safe is a sham: you'd expect safe to only allow mechanically verifiably code to get compiled but it doesn't. This is a PR problem. It's the same as @pure, you'd expect it to verify the referential integrity of a function, but it actually doesn't. If seen people invent to word 'weak purity' and 'strong purity' to cope with it. In practice, it's not really a problem but the PR around it is not nice.

2. relaxing @safe to allow unannotated externs will make it less useful, because in order to assess the memory safety in a reasonable way every part of the codebase, dependency and all transitive dependencies will need to be (manually) checked for unannotated externs, and this needs to be done every time you update your dependencies.

Only 1 could be thought of as greenwashing. I don't feel that's particularly convincing, but it also depends how safe-by-default is presented. There should be a huge caveat that it only applies to code the compiler can verify, and any unannotated code external to the compiler is assumed to be safe as well.

As for 2: for a lot of cases it will only be reasonable if the whole codebase including transitive dependencies can be mechanically checked on the usage of unannotated externs. Those should be banned in a quality check.

I know Walter hates warnings and thinks it should be in a linter, but this might be something the compiler could warn for and optionally treat as an error. The warning would also combat the false impression of wholesale greenwashing with a big 'told you so'.

On Thursday, 28 May 2020 at 01:23:31 UTC, Steven Schveighoffer wrote:
> On 5/27/20 8:31 PM, Jonathan M Davis wrote:
>> On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via Digitalmars-d wrote:
>>> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis wrote:
>>>> Based on some of Walter's comments, it also sounds like he
>>>> intends to make nothrow the default in another DIP, which is
>>>> also a terrible idea. I'm increasingly worried about the future
>>>> of D with some of where these DIPs are going.
>>>>
>>>> - Jonathan M Davis
>>>
>>> What's wrong with nothrow by default? Probably 97% of code
>>> doesn't need to throw exceptions.
>> 
>> If anything, I would say the opposite.
>
> It actually doesn't matter what's more common (and I agree with Jonathan, there's actually a lot of throwing calls because of the calls that you make into other functions). What matters is that there are functions that are actually nothrow that aren't marked nothrow. Hence the desire that these functions should actually be marked nothrow implicitly so people who care about that can just use the functions without issue.
>
> -Steve

What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ...

While I'm ok the "pay as you go" concept, I still think that a sane default for writing good code is still preferable: tuning the hot path is still the way to go if you care for speed.

The same for switching from "virtual by default" to "final by default", the motivation should not be "because the code is speedier", but because it's the best way to promote encapsulation of the class public API (as W&A agreed years ago ...)

The same for safety, if you don't care, well, slap @system everywhere, or @trusted if you want, anyway you are not caring. You just CAN code fast in that way. BUT if you care, you should have all the aid from the compiler to archive it, because writing @safe code is much more task, so @safe only for compiler checked code.

On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
>  since he won't listen

More accurately "does not agree".