Polysemous Values Qustion

Janice Caron caron800 at googlemail.com
Tue Sep 25 03:57:05 PDT 2007


On 9/25/07, Reiner Pope <some at address.com> wrote:
> Not sure of this, but perhaps it is to allow overloading by return value?
>
> int foo() { ... }
> long foo() { ... }
>
> auto x = foo();
> // x is polysemous, perhaps?

Or maybe

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'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 }.

In C++, on a 32-bit platform, the expression "0x10000 * 0x10000" will
yield zero. You have to explicitly make at least one them 64-bits
wide, e.g. "0x10000 * 0x10000LL", to stop the expression overflowing.
This would obviously be a huge boon to D.

Maybe that's what Walter means? I still don't get the notion of
runtime polysemousness.



More information about the Digitalmars-d mailing list