Value Preservation and Polysemy -> context dependent integer literals

[Andrei Alexandrescu]

Fawzi Mohamed wrote:
> On 2008-12-05 07:02:37 +0100, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> Sergey Gromov wrote:
>>> 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 any integral value carries:
>>
>> a) type as per the C rule
>>
>> b) minimum value possible
>>
>> c) maximum value possible
>>
>> The type stays the type as per the C rule, so there's no change there. 
>> If (and only if) a *narrower* type is asked as a conversion target for 
>> the value, the range is consulted. If the range is too large, the 
>> conversion fails.
>>
>> Andrei
> 
> basically the implicit conversion rules of C disallowing automatic 
> unsigned/signed conversions to unsigned?
> Fawzi
> 

Where's the predicate? I don't understand the question.

Andrei