RFC: scope and borrowing

[via Digitalmars-d]

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.