On Monday, 22 September 2014 at 15:54:23 UTC, Manu via
Digitalmars-d wrote:
We arrive at yet another case of "it should have been that way
from the
start" wrt 'scope'.
The baggage of annotation, and the lack of annotation to
existing code is a
pretty big pill to swallow.
If it were just part of the type, there would be no problem, T
would
already be 'scope T' in the cases where you expect. I can't see
any
disadvantages there.
But it has very different semantics. You cannot expect the same
code to work for scope and non-scope alike. And it is to be
expected that you have to adjust existing code if you want to
take advantage of a new feature. If by "it should have been that
way from the start" you mean that scope should be the default,
well yes, but we're in the same situation with immutable by
default, pure by default, @safe by default, nothrow by default,
... That ship has sailed, unfortunately.
I think UDA's are clearly distinct from ref and scope. UDA's
can attribute
types.
I strongly believe that the problem is the notion of a 'storage
class',
it's a faulty concept. It has never yet proven itself be what
I've ever
wanted in any case I'm aware of.
Your proposal even implies changes to the concept as it is;
like being able
to create a local that is 'scope'. Is that a recognition of
existing
problems? I've been asking for 'ref' local's for half a
decade...
That you can't declare ref locals is not inherent in the concept
of storage class. You can already today declare scope locals, it
just doesn't have an effect. And static is a storage class, too.
This would be another band-aid to a core problem. D already has
plenty of
these.
I hear this "perfect forwarding" concept thrown around, and I
think it's
another faulty concept. I rarely want 'perfect' forwarding...
why would I
be forwarding in the first place if it's 'perfect' (there are
cases, but
not so common)? I almost always want *imperfect* forwarding;
that is, some
small detail(/s) about the forwarding are manipulated. I think
this is the
primary case where storage class falls apart in concept.
That is a straw man. Of course, perfect forwarding needs to allow
for imperfect forwarding, too. It would indeed be not useful if
you couldn't inspect and modify the types (and storage classes)
of your parameters.
Maybe you can give counter examples too, if you think it
doesn't work.
It's complex and time consuming to do so. The situations where
it all
breaks down are often fairly complex (probably why 'ref' as a
storage class
seems like an okay idea at face value, although I still don't
understand
the advantage conceptually), and they tend to appear when you
don't expect
it. My examples with ref above are all practically applicable
to scope too
though.
A concrete example would still be very helpful to understand your
point of view. I.e., not only the concrete wrapper type/function,
but also how you would want to use it, and why it wouldn't work
without scope being part of the type.
Let's turn this around... Why the complexity? Why would you
make the change
to your proposal to make 'scope' something else outside of the
type system?
Well, I think Ivan gave an excellent example (ElementType) why it
should be separate from the type. Type modifiers currently only
deal with mutability (and the related shared). There can be some
nasty surprises if we add another concept there.
What is the advantage to that complexity. D has no structured
method for
dealing with that sort of meta, we only have types. Beyond
that, it's just
spaghetti, as we learn from ref.
Then it's better to introduce such a method, IMO.