Fri, 5 Dec 2008 12:24:27 +0100, Fawzi Mohamed wrote: > On 2008-12-05 02:53:11 +0100, Sergey Gromov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>> said: >>>> >>>>> Fawzi Mohamed wrote: >>>>>> On 2008-12-01 21:16:58 +0100, Walter Bright >>>>>> <[EMAIL PROTECTED]> 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.
