On Wed, Jan 15, 2020 at 05:16:18PM +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Tuesday, 14 January 2020 at 23:04:02 UTC, Adam D. Ruppe wrote:
> > On Tuesday, 14 January 2020 at 22:30:40 UTC, Walter Bright wrote:
> > > Hence, when "nothrow" becomes the default
> > 
> > IF, not when. I support this DIP as a nice independent move, but I am going to fight you on the step of changing the default.
> > 
> 
> +1 it's a strange misguided idea in the absence of something better than exceptions.
[...]

As I already pointed out in another thread, I suspect that Walter's beef against exceptions is not really the exceptions themselves, but their *current implementation* in the form of mandatory stack frames and their associated setup, and stack unwinding which is unwieldy to implement and expensive at runtime to execute.

Elsewhere in said other thread we've already come up with a potential alternative implementation that still allows you to throw errors -- just in a more lightweight form that doesn't require expensive stack frame setup and unwieldy stack unwinding code.  At the user code level, it could even retain exactly the same syntax, and work pretty much the same as before, just the actual implementation will follow a different scheme.


T

-- 
Too many people have open minds but closed eyes.

On Wednesday, 15 January 2020 at 18:20:00 UTC, H. S. Teoh wrote:
> As I already pointed out in another thread, I suspect that Walter's beef against exceptions is not really the exceptions themselves, but their *current implementation* in the form of mandatory stack frames and their associated setup, and stack unwinding which is unwieldy to implement and expensive at runtime to execute.

If that was the case then he would have suggested to fix the implementation, not the default...

You certainly can fix exception performance in the implementation with inter-procedural analysis.

> Elsewhere in said other thread we've already come up with a potential alternative implementation that still allows you to throw errors -- just in a more lightweight form that doesn't require expensive stack frame setup and unwieldy stack unwinding code.  At the user code level, it could even retain exactly the same syntax, and work pretty much the same as before, just the actual implementation will follow a different scheme.

D needs to use the same unwind code as C++ if it is going to integrate well with C++.

If C++ interop is the goal then D has to focus on aligning its semantics with C++... obviously.

On Wednesday, 15 January 2020 at 19:25:23 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 15 January 2020 at 18:20:00 UTC, H. S. Teoh wrote:
>> As I already pointed out in another thread, I suspect that Walter's beef against exceptions is not really the exceptions themselves, but their *current implementation* in the form of mandatory stack frames and their associated setup, and stack unwinding which is unwieldy to implement and expensive at runtime to execute.
>
> If that was the case then he would have suggested to fix the implementation, not the default...
>
> You certainly can fix exception performance in the implementation with inter-procedural analysis.
>
>> Elsewhere in said other thread we've already come up with a potential alternative implementation that still allows you to throw errors -- just in a more lightweight form that doesn't require expensive stack frame setup and unwieldy stack unwinding code.  At the user code level, it could even retain exactly the same syntax, and work pretty much the same as before, just the actual implementation will follow a different scheme.
>
> D needs to use the same unwind code as C++ if it is going to integrate well with C++.
>
> If C++ interop is the goal then D has to focus on aligning its semantics with C++... obviously.

Please everyone, let’s keep this thread focused on reviewing this DIP. There is another thread discussing default nothrow. Any further off topic posts in this thread will be deleted.

Thanks!

On 1/14/20 3:28 PM, Walter Bright wrote:
> On 1/14/2020 3:21 AM, WebFreak001 wrote:
>> I don't think making the attribute "throw" is the best way to go though. Currently most attributes use the at-attribute syntax which makes them very unambiguous and easier to (visually) parse. I would suggest instead of having throw as attribute, the new attribute should be @throws instead. `throws` can also be argued for that it is "better" to read like: "function foo throws" than "function foo throw"
> 
> It's already a keyword so there's no problem with having it be 'throw'.
> 
> Having 'throw', 'nothrow' and 'throws' as keywords looks excessive.
> 
> 
>> Additionally if we make this an at-attribute, it can very easily be extended in the future to have arguments what kind of exceptions are being thrown by this function, for example using template argument syntax to be the easiest and most consistent to parse. This also exists in other languages like Java and helps both with linting for try-catch, but also extremely helps with documentation.
>>
>> For symmetry with nothrow it might be worth looking into providing nothrow as @nothrow attribute instead too.
> 
> The @ syntax for this is simply unnecessary.
> 

Walter:

To back up WebFreak001's assertions: the seemingly random keyword versus @attribute decorators for functions are very jarring and disconcerting for new and even intermediate users.

This is a perfect opportunity to harmonize things that, for very little downside, improve the apparent coherence of the language.

"throws" also sounds far more grammatical than "throw"

On 1/15/2020 7:26 AM, Arine wrote:
> I'm completely blown away, you don't even know that @safe passes through to the next scope?

My mistake. What actually happens is here:

    sc2.stc &= STC.safeGroup;

    https://github.com/dlang/dmd/blob/master/src/dmd/aggregate.d#L136

where the storage class passed from the outer scope to the struct/class scope is zeroed out except for @safe/@trusted/@system.

So @safe "flows through" to the struct scope, while nothrow, pure, @nogc, etc., do not.

For functions, the line is:

  sc2.stc &= ~(STC.auto_ | STC.scope_ | STC.static_ | STC.extern_ | STC.abstract_ | STC.deprecated_ | STC.override_ |
               STC.TYPECTOR | STC.final_ | STC.tls | STC.gshared | STC.ref_ | STC.return_ | STC.property |
               STC.nothrow_ | STC.pure_ | STC.safe | STC.trusted | STC.system);

   https://github.com/dlang/dmd/blob/master/src/dmd/semantic3.d#L316

Interestingly, @nogc does flow through here.

So, the flow through behavior depends on the attribute. My mistake I did not check first before posting.

https://github.com/dlang/dmd/pull/10728

On 16.01.20 09:04, Walter Bright wrote:
> 
> For functions, the line is:
> 
>    sc2.stc &= ~(STC.auto_ | STC.scope_ | STC.static_ | STC.extern_ | STC.abstract_ | STC.deprecated_ | STC.override_ |
>                 STC.TYPECTOR | STC.final_ | STC.tls | STC.gshared | STC.ref_ | STC.return_ | STC.property |
>                 STC.nothrow_ | STC.pure_ | STC.safe | STC.trusted | STC.system);
> 
> https://github.com/dlang/dmd/blob/master/src/dmd/semantic3.d#L316
> 
> Interestingly, @nogc does flow through here.

This is just plain broken and cannot be explained as anything but as an oversight. It's the root cause of this issue:
https://issues.dlang.org/show_bug.cgi?id=18439

Why should nogc functions not be able to use the GC within lambdas that are executed exclusively during CTFE?

On 16.01.20 09:35, Timon Gehr wrote:
> On 16.01.20 09:04, Walter Bright wrote:
>>
>> For functions, the line is:
>>
>>    sc2.stc &= ~(STC.auto_ | STC.scope_ | STC.static_ | STC.extern_ | STC.abstract_ | STC.deprecated_ | STC.override_ |
>>                 STC.TYPECTOR | STC.final_ | STC.tls | STC.gshared | STC.ref_ | STC.return_ | STC.property |
>>                 STC.nothrow_ | STC.pure_ | STC.safe | STC.trusted | STC.system);
>>
>> https://github.com/dlang/dmd/blob/master/src/dmd/semantic3.d#L316
>>
>> Interestingly, @nogc does flow through here.
> 
> This is just plain broken and cannot be explained as anything but as an oversight. It's the root cause of this issue:
> https://issues.dlang.org/show_bug.cgi?id=18439
> 
> Why should nogc functions not be able to use the GC within lambdas that are executed exclusively during CTFE?

Also, alarmingly, 'pure' the same issue even though it appears in that expression:

int bar(){ return 2; }
pure @nogc:
auto foo(){
    enum x={ return bar(); }(); // error for no reason
}
pragma(msg, typeof(&foo));

I.e., the compiler contains additional logic for `pure` that makes it broken even though there is no reason to treat it any differently to, e.g., nothrow.

On Thursday, 16 January 2020 at 08:47:01 UTC, Timon Gehr wrote:
> Also, alarmingly, 'pure' the same issue even though it appears in that expression:

Since lambdas are inferred, the attr: should not apply to them anyway. That's my proposal - exempt anything that is inferred from the attr: things (you can still attach attributes directly to it to force the issue).

There's no reason to force the issue with these; attr: is to kinda change the default and inference already is a more generally useful default.

On Thursday, 16 January 2020 at 02:27:22 UTC, James Blachly wrote:
> This is a perfect opportunity to harmonize things that, for very little downside, improve the apparent coherence of the language.
>
> "throws" also sounds far more grammatical than "throw"

On top of that having all attributes with @ syntax would allow for them to be defined as simple UDAs in runtime, make them available for introspection in templated code and allowing to getting rid of functionAtrributes traits. Moreover this would allow easy extension of those attributes with additional data, be it template arguments or struct fields.

Best regards,
Alexandru.