Value Preservation and Polysemy -> context dependent integer literals

[Sergey Gromov]

Fri, 5 Dec 2008 12:24:27 +0100, Fawzi Mohamed wrote:

> On 2008-12-05 02:53:11 +0100, Sergey Gromov <snake.scaly at gmail.com> said:
> 
>> Thu, 04 Dec 2008 09:54:32 -0800, Andrei Alexandrescu wrote:
>> 
>>> Fawzi Mohamed wrote:
>>>> On 2008-12-01 22:30:54 +0100, Walter Bright <newshound1 at digitalmars.com>
>>>> said:
>>>> 
>>>>> Fawzi Mohamed wrote:
>>>>>> On 2008-12-01 21:16:58 +0100, Walter Bright
>>>>>> <newshound1 at digitalmars.com> said:
>>>>>> 
>>>>>>> Andrei Alexandrescu wrote:
>>>>>>>> I'm very excited about polysemy. It's entirely original to D,
>>>>>>> 
>>>>>>> I accused Andrei of making up the word 'polysemy', but it turns out
>>>>>>> it is a real word! <g>
>>>>>> 
>>>>>> Is this the beginning of discriminating overloads also based on the
>>>>>> return values?
>>>>> 
>>>>> No. I think return type overloading looks good in trivial cases, but
>>>>> as things get more complex it gets inscrutable.
>>>> 
>>>> I agreee that return type overloading can go very bad, but a little bit
>>>> can be very nice.
>>>> 
>>>> Polysemy make more expressions typecheck, but I am not sure that I want
>>>> that.
>>>> For example with size_t & co I would amost always want a stronger
>>>> typechecking, as if size_t would be a typedef, but with the usual rules
>>>> wrt to ptr_diff, size_t,... (i.e. not cast between them).
>>>> This because mixing size_t with int, or long is almost always
>>>> suspicious, but you might see it only on the other platform (32/64 bit),
>>>> and not on you own.
>>>> 
>>>> Something that I would find nice on the other hand is to have a kind of
>>>> integer literals that automatically cast to the type that makes more sense.
>>> 
>>> Wouldn't value range propagation take care of that (and actually more)?
>>> A literal such as 5 will have a support range [5, 5] which provides
>>> enough information to compute the best type down the road.
>> 
>> It sounds very nice and right, except it's incompatible with Cee.
>> 
>> Well, you can safely reduce bit count so that assigning "1025 & 15" to
>> "byte" would go without both a cast and a warning/error.  But you cannot
>> grow bitcount beyond the C limits, that is, you cannot return long for
>> "1024 << 30."  You should probably report an error, and you should
>> provide some way to tell the compiler, "i mean it."
>> 
>> In the worst case, any shift, multiplication or addition will result in
>> a compiler error.  Do I miss something?
> 
> well what I would like to have is 1024 << 30 to be acceptable as long 
> as it is then stored in a long.
> With Polysemy I am not sure about what the result should be.

The result should be either 0 or a compile-time error because C requires
this to evaluate to 0.