D's greatest mistakes
Jonathan M Davis
jmdavisProg at gmx.com
Mon Nov 29 12:51:22 PST 2010
On Monday, November 29, 2010 11:03:27 Andrei Alexandrescu wrote:
> On 11/29/10 12:56 PM, Michel Fortin wrote:
> > On 2010-11-29 13:08:54 -0500, Andrei Alexandrescu
> >
> > <SeeWebsiteForEmail at erdani.org> said:
> >> On 11/29/10 10:54 AM, Michel Fortin wrote:
> >>> The biggest problem I see is with generic programming. Say I pass
> >>> Rebindable!(const C) as a template argument, then the template wants to
> >>> make it const: should it become const(Rebindable!(const C)), or will
> >>> this be resolved to const(C)?
> >>
> >> const should follow normal logic, and const(Rebindable!(const C))
> >> should behave as expected.
> >
> > I think we agree on that.
> >
> > The problem is that you now have two distinct types to mean a const
> > reference to a const object. You have "const(Rebindable!(const C))" and
> > const "const(C)", whichever you get depends on where the type comes
> > from. Type equality won't work between the two, and you won't be able to
> > concatenate two arrays one containing rebindables and the other (for
> > instance). It's like a special case in the type system where constness
> > is implemented using a template while the rest is a language feature, it
> > it thus behave differently and code that might work for one
> > implementation of constness might break with the other, because the
> > don't play with each other very well. Add immutable to the mix and it
> > becomes even stranger.
> >
> > For instance, here's a tricky question: should Unqual!(const C) give you
> > a const(C), a Rebindable!(const C), or simply C?
>
> C.
>
> > Now, what should
> > const(Unqual!(immutable C)) give you?
>
> const(C).
>
> > I know most of the problems are going to be edge cases most people don't
> > care about. But on the whole, creating a fragile and complex solution to
> > work around the lack of an inspiring syntax seems rather silly. I would
> > immensely prefer having an ugly syntax that works as it should. If it's
> > too ugly, we can still hide that syntax behind Rebindable by defining it
> > as a simple type alias.
>
> Rebindable, if properly executed, is not fragile and complex. Instead it
> is a simple solution for a specific problem: I want a class reference
> that I need to bind to different const class objects. If you apply const
> to Rebindable, normal rules enter in action. I agree that a built-in
> component can be made nicer by adding extra short-circuit rules.
For Rebindable to actually be as good as a built in feature, it needs to act
like a built in feature as far as its abilities go, and it doesn't - the lack of
opImplicitCast() being one of the big problems.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list