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