DIP 1029---Add throw as Function Attribute---Community Review Round 1

jmh530 john.michael.hall at gmail.com
Tue Jan 14 21:37:42 UTC 2020


On Tuesday, 14 January 2020 at 20:35:44 UTC, Walter Bright wrote:
> [snip]
>
> Because it's the way the other attributes work. Trying to 
> change this would be very disruptive. The reason it works this 
> way is it is unkind to the purpose of scoping. If the 
> attributes passed into nested scopes, then you'll pretty much 
> force a coding guideline to "list all the attributes needed at 
> the beginning of each scope" so it won't silently break when 
> someone adds a:
>
>  attribute:
>
> at the top.
>
> [snip]

I agree that it is disruptive, but I would hang my hat on the 
argument not being germane because such a change would affect 
other attributes as well. Keeping the change small is good, IMO.

Nevertheless, I think a case could be made for changing the 
behavior. However, I would limit the change to
attribute:
while keeping the behavior of
attribute { code }
unchanged.

I would phrase this as attribute: being for scope-wide defaults 
(including nested), while attribute { code } would be for 
scope-level defaults only. That makes these two features a bit 
more orthogonal, though potentially at a cost of some disruption.

However, attribute: can currently be replaced by an attribute { 
code } wherever it is used. That means that if you change 
attribute: to pass into nested scopes, while leaving attribute { 
code } unchanged, then any code that could be broken by the 
change could be easily fixed by using attribute { code }. It 
becomes a lot more disruptive if you change attribute { code } 
too.



More information about the Digitalmars-d mailing list