Janice Caron wrote:
> In another thread, Christopher Wright said that polysemous meant "A
> variable that can have several types depending on how it is assigned
> or casted is polysemous. Walter wants to use this especially for
> string literals -- should it be fixed length or not, should it be
> char, wchar,
> dchar?"
> 
> And then Don Clugston said "For example, the literal number 1. Could
> be a short, int, uint, float, complex number,..."
> 
> Both of those examples are LITERALS. I get that. Literal can be
> interpreted as either one type or another. It makes sense that you'd
> want to delay nailing down the decision until you really have to.
> 
> But CW said: "A /variable/..." (my emphasis). Can you have a
> polysemous variable (as opposed to literal)? I don't get how that
> would work.

AFAIK, it only applies to rvalues (which is a bit broader than simply literals).

Christopher Wright wrote:

> If Walter's reading this, he's probably thinking that it's a bad idea to allow any type to be unresolved for very long, given the problems people have mentioned. And if not, well, that might be reason enough for me to stick with D2 rather than going with D3. (I hate, hate, HATE languages where it's nontrivial to tell the effective type of something.)

Well AFAICS the polysemous type is an extension to the current type system. So if you want to explicitly declare all types, you're still free to do so. It's like the new constness, but in this case types are still backwards compatible. Btw, a modern IDE can easily determine the inferred type by doing on the fly semantic analysis and visualize the set of possible types. In case you haven't noticed, even D 1.x allows you to write long functions without binding any concrete types, for example:

T fun(T, U, ...)(T t, U u, ...) {

 // some code

 auto foo = t.children;

 auto bar = foo.first;

 foreach(c; foo) {
   if (bar < c) bar = c;
 }

 // more code

}

downs wrote:

> Nathan Reed wrote:
>> Robert Frser wrote:
>>> Can someone giv me an example where polysemous values could apply to a
>>> class (given the class has (multiple) opImplicitCastTo/From)
>> 
>> Here's another example where polysemous values could come in handy:
>> 
>> interface A { ... }
>> interface B { ... }
>> 
>> class Foo : A, B { ... }
>> class Bar : A, B { ... }
>> 
>> void main (string[] args)
>> {
>>     bool flag = ...
>>     auto whatsMyType = flag ? new Foo : new Bar;
>> }
>> 
>> Here, Foo and Bar both implement A and B, so the variable 'whatsMyType' could have either type A or type B.  If you do this in D now, it will fail with a compile error, since Foo and Bar have no least upper bound...but with polysemous values, whatsMyType could have type "A or B".
>> 
>> Thanks,
>> Nathan Reed
> 
> I don't think it can.
> Polysemous values are values that can be interpreted as more than one
> type simultaneously. whatsMyType can be interpreted as either Foo or
> Bar, but not both at the same time - whichever one is correct at
> runtime, the other one isn't.

Types of "new Foo" and "new Bar" can be [Foo, Object, A, B]. (ok, maybe also
void*)

If in the type world ?: is a function (x,y) -> (z) where z belongs to both x
and y, "flag ? new Foo : new Bar" can very well be [Object, A, B], and by
the same logic so can also "whatsMyType", because typewise = is probably a
function (x) -> (x).

Jari-Matti Mäkelä wrote:

> Types of "new Foo" and "new Bar" can be [Foo, Object, A, B]. (ok, maybe
> also void*)

Heh, I optimized away something. Type of "new Bar" is more likely a subset of these [Bar, Object, A, B]. :)