Polysemous Values Qustion

[Matti Niemenmaa]

Disclaimer: I don't know anything. My thoughts in any case:

Janice Caron wrote:
> auto x = 7;
> 
> means that x is polysemous? (any type capable of being initialised
> with 7)? And if we then say
> 
> ulong y = x;
> 
> would that retrospectively establish that typeof(x) is ulong?

I don't think so, because couldn't you still do:

short z = x;

If you couldn't, this would be a huge problem. Imagine the following:

auto x = 5;
// ...
short y = x;

Then somebody adds "ulong z = x;" to somewhere within the "...", between the
initializations of x and y. Suddenly, the line "short y = x" doesn't compile
because of something which should be unrelated.

I think typeof(x) remains { byte, ubyte, short, /+ ... +/ } no matter what you
do with it.

I'm not sure how thinking about the typeof(x) would play with opImplicitCast
(assuming such a thing will come). typeof(x) could change depending on what
classes are visible from where x is declared. Maybe there's just an "any class
with an opImplicitCast to any of my other types" type.

> ...I'm still very confused. However, it would also make sense if
> polysemous was a compile-time type, whose interpretation (at compile
> time) is "the type of this value is one of { T, U, V, ... }, and then
> you narrow down the list as you evaluate the expression in which it
> occurs. For example
> 
> auto z = 0x10000 * 0x10000;
> 
> Here the compiler must multiply one polysemous type by another. Both
> values are known at compile time, and both could be { int, uint, long,
> ulong } but the result (0x100000000) is too big to fit into an int or
> uint, and so must be constrained to one of { long, ulong }.

That's how I see it. typeof(z) == [ long, ulong, class with opImplicitCast to
long or ulong ]. And cent and ucent of course, they might be around by the time
this is implemented. ;-)

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi