const challenge
Russell Lewis
webmaster at villagersonline.com
Tue Feb 5 09:22:19 PST 2008
Janice Caron wrote:
> On 04/02/2008, Russell Lewis <webmaster at villagersonline.com> wrote:
>> Janice Caron wrote:
>>> On 03/02/2008, Russell Lewis <webmaster at villagersonline.com> wrote:
>>>> If we had a opImplicitCast (and it was overloadable), then it would be
>>>> pretty easy to implement a template with thunks:
>>> It would - but you'd quickly find ambiguities, at which the compiler
>>> would also complain, again requiring an explicit cast to keep the
>>> compiler happy.
>> Can you expand on this?
>
> Sure. If one function, f, returned PolysemousContainer(A,B), and
> another function, g, was overloaded thus:
>
> g(A a) { /* do something */ }
> g(B b) { /* do something else */ }
>
> then the expression
>
> g( f( ) )
>
> would be ambiguous.
Ok, good point. But, IMHO, that isn't a good argument against
polysemous types. Remember that we already have that problem with
various built-in types which have multiple possible implicit casts (such
as numeric types). IMHO, the problem is not a problem with the
polysemous type, but with the *user* of a polysemous type, and in that
case, it is quite reasonable to require the user to resolve the ambiguity.
For users which don't have any ambiguity, polysemous types express a
clear and very useful thing: "There are two or more perfectly valid ways
to express this value. Which do you want?"
More information about the Digitalmars-d
mailing list