The point of const, scope, and other attributes

[jmh530]

On Wednesday, 11 May 2022 at 05:02:31 UTC, Walter Bright wrote:
> The original D did not have them.
>
> [snip]

I'm generally pro-attribute, but I can't help but find myself 
scratching my head a bit with when to use return ref scope. And 
then for whatever reason there was a change so that now scope 
return has to be return scope.

So I think it might help to lay out some principles vis a vis 
attributes.

The first principle I would emphasize is "time to first plot". I 
learned about this from the Julia language, where they are 
talking about actual time it takes for Julia to boot up and be 
able to plot something. However, I think you can think about it a 
bit more metaphorically as "time for a new user to do something." 
This principle implies that D's opt-in approach to attributes is 
good since a new user can start doing work without needing to 
worry about them at first. On the basis of this principle, moving 
toward @safe by default or const/immutable by default would be 
bad.

The second principle is harder to describe, but it is related to 
the relationship between complexity, levels of abstraction, and 
mental burden. In the back of my head, I am recalling a chart 
that compared C++ and D with D listed as less complex than C++ (I 
don't recall what the other axis was, maybe something like 
expressive power). Anyway, if a programming language is 
considering adding a feature and there is a less complex version 
that abstracts away from some details versus a more complex 
version that operates on a higher level of abstraction, then it 
can be the case that the more complex version operating on a 
higher level of abstraction might actually have a lower mental 
burden. Consider the treatment of lifetimes in DIP 1000 vs 
lifetimes in Rust. DIP 1000's use of return probably covers most 
peoples' use cases, but might also require a higher mental burden 
to figure out exactly what it means since it is less abstract. By 
contrast, Rust lifetimes are implemented in a more complex way, 
but also operating at a higher level of abstraction. The higher 
level of abstraction might also result in a lower mental burden. 
Long story short, sometimes adding a more complex feature can be 
a good thing if it comes associated with a higher level of 
abstraction.

Of course, the trade off between the complexity and the ability 
to generate improved performance/safety is another important 
principle.