On 2010-08-16 10:03:58 -0400, "Steven Schveighoffer" <schvei...@yahoo.com> said:

On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin <michel.for...@michelf.com> wrote:

I think what you want for that is to somehow make SmartPtr!(X) implicitly derived from SmartPtr!(const X), you don't want the compiler applying blindly tail-const to all the members.

Again, it's logical const, no matter how you slice it.

If you see it that way, then D const is logical const too. I'm not proposing we create a mutable island inside a const struct or class (thus not breaking the transitivity), so it does abide by D current definition of const. Here's some definition?

        struct SmartPointer(T) {
                T* pointer;
                uint* refCount;
        }

        SmartPointer!(const X) pointer;

All I am saying is that the "conceptual" tail-const form of SmartPointer!(X) is SmartPointer!(const X), and that it'd be useful that SmartPointer!(X) and SmartPointer!(immutable X) could implicitly cast to SmartPointer!(const X). That might be "logical const" to you as long as you think "tail const" for struct is "all members become tail const", but I think that definition of tail-const is pointless and that there should not be any real tail-const for structs except the one you can induce through its template arguments.

As for constness of ranges, it's quite similar. The thing is that you generally have three possible levels of constness. The range might be const, the container the range points to might be const, and the elements in the container might be const. If ranges were expressed like this:

        struct Range(ContainerType) {...}

then it'd be easy to say whether the container and the element type is const or not just like this:

        Range!(Container!(const Element))
        Range!(const Container!(immutable Element))
        Range!(immutable Container!(immutable Element))

Most ranges are not defined like this: the type of the containeris implied in the type of the range, but the constness of the container is simply missing. Wouldn't defining ranges like the above fix the problem? And you could make ranges cast implicitly to their "tail-const" form when needed, exactly like the smart pointer above.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Reply via email to