Greenwashing

[Andrei Alexandrescu]

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.