On Monday, 15 December 2014 at 06:12:05 UTC, Walter Bright wrote:
C++ seems to do fine without it for const. It's a convenience
feature.
C++ const does not really restrict or affect anything "for real",
it is non-existent feature. `scope` as proposed would result in
inability to store result of predicates if those are ever to
accept scope data - unless you defined two versions for each
function that may possibly accept scope data with absolutely
identical body.
2. This is what scope inference is all about.
Which only works with templates and lack of scope on arguments
does not affect
function body -> templates are not necessary, same as inout.
It also works with all the lambdas, since source for them is
always available. I also wanted to make it (i.e. inference)
work with auto functions, but Don Clugston was the primary
objector :-)
This is not really answering my objections but side-stepping. I
do support attribute inference. I would actually support full
attribute inference in the language (and help convincing Don
about it ;)) if it was introduced as foundation of the language
and not arbitrary hack (== rethink the way .di interfaces and
static libraries are defined)
I do view inference as something we need to extend to more
functions.
That would help with many issues but it need careful design to be
well-accepted. How about teaming up to do a DIP about it at some
point where this discussion is over? :P
2) at least optional transitivity to be able to express to
protect with scope
data referenced by slice or owned linked list referenced
from root node.
1. that won't work unless scope is a type constructor
I know and this is why I am leaning toward it being qualifier
despite all
related issues.
That would be a truly massive change to D, and I'm not at all
sure it would be worth it. We've (i.e. Kenji) have been fixing
bugs with inout for years, and idea that had seemed
straightforward.
Yes, I know and this why I am leaning towards that path but
willing to accept any storage-class based solution - as long as
it fits my basic criteria. I wonder if some hybrid approach is
possible - for example, keep it storage class but pretend
anything transitively accessible though it as if it was of scope
storage class on its own. But that quickly gets into "exceptions
for special cases" land :(
2. it can be achieved by using wrappers that only allow
by-scope references to
their data (RC is an example of such a wrapper)
It is viral approach and backwards incompatible one - we can't
change signatures
of Phobos functions to return Wrapped!(char[]) instead of
char[] for example.
While theoretically possible I can't call this approach
practical - not until
see some convincing application example.
But you can change signatures to add annotations?
Such annotation would only prevent from compiling code which was
already undefined by documentation. Changing return type (which
wasn't Voldemort type before) may break any program that has
lines akin to `char[] data = foo()` - perfectly legal working
code.
This sounds totally against my understanding of scope. I want
scope exactly to
prohibit such actions. However it is possible in slightly
modified way - where
you don't directly insert pointer to AST but use public method
of AST control
structure that checks if supplied scope pointer belongs to
list of nodes it
owns and casts away scope after that.
Wrappers do that, too.
I know that 'wrapper' sounds bad to you, but one of the goals
of D's UDT's is to make it easy to adapt the behavior of a type
by wrapping it in a struct, rather than build new behavior into
the language.
Problem is that our UDT are simply not that good enough yet.
Wrappers are fine in general but I want to wrap for less common
cases and support more common ones natively. I suppose this is
your intention too but we disagree on what is actually the common
case and what is the special case.
