On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
> On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
>> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
> 
> You'd just have to write them out there.

Not possible in some cases (@throws, @gc, @impure)

> 
>> 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example).
> 
> Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version

Sure, that's a reasonable expectation.

-steve

On Thursday, 28 May 2020 at 16:47:01 UTC, Steven Schveighoffer wrote:
> On 5/28/20 12:39 PM, Adam D. Ruppe wrote:
>> On Thursday, 28 May 2020 at 15:12:56 UTC, Steven Schveighoffer wrote:
>>> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
>> 
>> You'd just have to write them out there.
>
> Not possible in some cases (@throws, @gc, @impure)
>
>> 
>>> 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example).
>> 
>> Eeeeeeh, I'd be ok with that but it would need to actually point out that it was inferred - that this is NOT a promise of forward compatibility, it just happens to be so in this version
>
> Sure, that's a reasonable expectation.
>
> -steve

I am all for nonothrow and nononothrow (which does not allow asserts :))

On Thursday, 28 May 2020 at 18:09:51 UTC, Stefan Koch wrote:
> I am all for nonothrow and nononothrow (which does not allow asserts :))

nonononononotheresnolimits ;-)

On Thursday, 28 May 2020 at 19:08:18 UTC, Joseph Rushton Wakeling wrote:
> On Thursday, 28 May 2020 at 18:09:51 UTC, Stefan Koch wrote:
>> I am all for nonothrow and nononothrow (which does not allow asserts :))
>
> nonononononotheresnolimits ;-)

In the context of DIP 1028, I really want an attribute called
@nojustno that I can put at the top of my source file to make
extern(C) declarations @system by default. ;-)

On Thursday, 28 May 2020 at 00:31:09 UTC, 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.
>
> <snip>

I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.

On Thursday, 28 May 2020 at 15:23:49 UTC, Paolo Invernizzi wrote:
> On Thursday, 28 May 2020 at 12:21:31 UTC, welkam wrote:
>> On Thursday, 28 May 2020 at 07:36:05 UTC, Paolo Invernizzi wrote:
>>
>>> tuning the hot path is still the way to go if you care for speed.
>>
>> You havent done many optimizations have you?
>
> For sure I have ...
Am I the only one that find the common saying that 20% of code is responsible for 80% of runtime to be not true? In my experience its either 5% eating up 90% of runtime (a stupid mistake) or the slowness spread out trough out the codebase. Have I not seen enough cases?

On 5/28/20 9:42 AM, Joseph Rushton Wakeling wrote:
> On Wednesday, 27 May 2020 at 23:57:00 UTC, Meta wrote:
>> What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
> 
> One point of view can be to consider the consequences of fixing code that incorrectly uses the default.
> 
> If we have throws-by-default, then marking an existing non-templated method `@nothrow` is not a breaking change.
> 
> If we have nothrow-by-default, then marking an existing non-templated method `@throws` is a breaking change.
> 
> Another point of view could be that there's a benefit to being permissive by default in terms of what the developer can do.

And that should be a breaking change. So all is good.

Changing the regime of a function from nothrow to throw is major.

I'm sympathetic with making functions nothrow the default. The reader and compiler taking into account the possibility of throwing is a large upfront tax. That should not be paid without necessity.

On 5/28/20 11:16 AM, Paolo Invernizzi wrote:
> On Thursday, 28 May 2020 at 15:00:11 UTC, Steven Schveighoffer wrote:
>> On 5/28/20 3:36 AM, Paolo Invernizzi wrote:
>>> 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.
>>>>
>>>
>>> What make me feel "mhmm" is that the motivation is always "because no throw is speediest, so should be the default" ...
>>
>> That's not the motivation for the default.
> 
> DIP 1029, Rationale:
> 
> "The problem is that exceptions are not cost-free, even in code that never throws. Exceptions should therefore be opt-in, not opt-out. Although this DIP does not propose making exceptions opt-in, the throw attribute is a key requirement for it. The attribute also serves well as documentation that yes, a function indeed can throw."
> 
> Maybe I'm wrong, but when Walter uses "not cost-free" he seldom refers to something else than ... speed.

There's cognitive cost, too. Coding with functions that throw is a lot more difficult.

On 5/28/20 11:12 AM, Steven Schveighoffer wrote:
> On 5/28/20 10:53 AM, Joseph Rushton Wakeling wrote:
>> On Thursday, 28 May 2020 at 13:53:39 UTC, Adam D. Ruppe wrote:
>>> The beauty of inferred by default is neither are breaking changes.
>>
>> Not sure I agree about that TBH.  Inferred-by-default just means the function signature doesn't by default tell you anything about what properties you can rely on, and any change to the implementation may alter the available properties, without any external sign that this has happened.
> 
> 1. Templates already do this, and it has not been a problem (much of Phobos and much of what I've written is generally templates).
> 
> 2. If we went to an "inferred-by-default" regime, there would have to be a way to opt-out of it, to allow for crafting attributes of public extern functions.
> 
> 3. You would still need to specify exact attributes for virtual functions.
> 
> 4. Documentation should show the inferred attributes IMO (not sure if this already happens for auto functions for example).
> 
> 5. Yes, inferred attributes might change. This would be a breaking change. It might be a breaking change for others where it is not for the library/function in question. But it would still be something that IMO would require a deprecation period. For things outside our control, it's very possible that these changes would be done anyway even if they were actual attributes.
> 
> 6. One might also take the view that a lack of attributes means the function may or may not have those attributes inferred in the future (i.e. it's not part of the API). I think much code is already written this way.

Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.

On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.

We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....