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