On 2008-12-05 16:27:01 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Fawzi Mohamed wrote:
>> On 2008-12-05 07:02:37 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>> 
>>> [...]
>>> 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

The implicit conversion rules in C when performing arithmetic operations allow up-conversion of types, basically the largest type present is used, which almost already respect a,b,c: (using C names)

1) if long double is present everything is converted to it
2) otherwise if double is present everything is converted to it
3) otherwise if float is present everything is converted to it

if only signed or only unsigned integers are present the are ranked in the following sequence
	char, short, int ,long,long long
and everything is converted to the largest type (largest rank)

If the range of the signed integer include the range of the unsigned integer everything is copied to the signed type
these rules respect a,b,c

for example
   ushort us=1;
   printf("%g\n",1.0*(-34+us));
prints -33, as one would expect.

Now the two rules that break this and that you want to abolish (or at least you have problems with) if I have understood correctly are
* if the signed number has rank<= the unsigned convert to the unsigned
* otherwise the unsigned version of the signed type is used.
Is this correct? did I understand what you mean correctly? this is what polysemy does?

I agree that in general these two last rules can bring a little bit of confusion
   printf("%g\n",1.0*(-34+1u));
   printf("%g\n",1.0*(-34+1UL));
   printf("%g\n",1.0*(-34-1u));
prints
   4.29497e+09
   1.84467e+19
   4.29497e+09
but normally it does not matter, because the bit pattern is what one expects, and casting to the correct type one has the correct result
   printf("%g\n",1.0*cast(int)(-34+1u));
   printf("%g\n",1.0*cast(long)(-34+1UL));
   printf("%g\n",1.0*cast(int)(-34-1u));
prints
-33
-33
-35
and the advantage of combining freely signed and unsigned without cast (and it happens often)  I think out weights its problems.

The only problem that I have seen connected to this is people thinking
	opCmp =	cast(signed)(unsigned-unsigned);
which is wrong.

What I would like to have is
1) adaptive integer literals

For one kind of integer literals, optimally the decimal literals without prefix, and introducing a prefix for int integer literals (yes in my first message I proposed the opposite, a prefix for the new kind of literals, but I changed idea already in the second one) to have a very lax regime, based of value preservation:
- all calculations of these integer literals between themselves are done with arbitrary precision
- this literal can implicitly cast to any type as long as the type can represent the value (that is obviously known at compile time)
- for matching overloaded functions one has to find a rule, this is something I am not too sure about, int if the vale fits in it, long if it doesn't and ulong if it does not fit in either could be a possibility.

2) different integer type for size_t ptr_diff_t (and similar integer types that have the size of a pointer)

no cast needed between size_t and ptr_diff_t
cast needed between them and both long and int

Fawzi

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

> On 2008-12-05 02:53:11 +0100, Sergey Gromov <snake.scaly@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@digitalmars.com> said:
>>>> 
>>>>> Fawzi Mohamed wrote:
>>>>>> On 2008-12-01 21:16:58 +0100, Walter Bright <newshound1@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.