On 2010-12-07 09:05:20 -0500, Jason House <[email protected]> said:
Michel Fortin Wrote:
The point is that the 'ref' in in the 'b' and 'c' variable declaration
has the effect of changing the ref from B and C from const to mutable,
even for B where the ref was explicitly specified to be const. I was
wondering if some people would find that surprising, but if I
understand you well that's what you expect when seeing this, right?
I've been wondering if it makes more sense for 'ref' to be a storage
class rather than some kind of type constructor. Doing that would make
the typedef's with ref be illegal. It'd also make foo!(const(T) ref) be
illegal as well as (const(T) ref)[]. As a storage class, it can only be
added to variable declarations.
I think the array case would be missed. I'm not sure what people would
think of the template case, especially when it pops up in code such as
foo!(typeof(x)). If ref isn't a storage class, then generic programmers
will need an equivalent to unqual that only strips the outer-most ref.
As a storage class typeof would not return the ref. How do templates
work with your patch?
From my tests, templates work as they should. For instance, I can
easily call std.algorithm.sort on an array of const(Object)ref. Which
brings the question: how do you do that if 'ref' is a storage class? :-)
The way I implemented the feature in the compiler is that I added the
notion of head-modifiers for types. For most types, head-modifiers are
just a pointer to the regular modifiers, so they're always identical.
But for a class type, encountering a 'ref' suffix changes the
head-modifiers to match those applied to the suffix. Then when
declaring a variable, when the compiler deduces the storage class for
that variable from its type, I changed it so it checks the
head-modifiers of the type instead of its regular modifiers. A few
other tweaks like that were required to make it work with foreach and
array ops, but the end result is a very small change to the compiler
that fits reasonably well within the type system.
--
Michel Fortin
[email protected]
http://michelf.com/
