proposed syntax change

Robert Jacques sandford at jhu.edu
Thu Aug 6 15:02:00 PDT 2009


On Thu, 06 Aug 2009 13:34:21 -0700, Yigal Chripun <yigal100 at gmail.com>  
wrote:

> Ary Borenszweig wrote:
>> Adam D. Ruppe wrote:
>>> On Thu, Aug 06, 2009 at 03:06:49PM -0400, Paul D. Anderson wrote:
>>>> Oh wait...I think "//" is used elsewhere.
>>>
>>> Is this a joke?
>>  No. When porting C, C++, Java or C# code just search "//" and replace  
>> it with "--".
>>  Oh wait... I think "--" is used elsewhere.
>
> Why would I as a user want to have two ops that do the same thing?!
> Python's solution for this is wrong IMHO since the problem is not with  
> the op itself but rather with the way C handles numbers.
>
> 5 / 2 should always be the more precise FP division unless the compiler  
> knows or is instructed to do otherwise.
>
> int a = 5 / 2; // compiler knows to use integer division

No, it doesn't. (i.e. Welcome to the limitations of a context-free  
grammar) The right hand of the expression has to be evaluated before the  
left, or otherwise function overloads, etc, don't work, so there's no way  
for the compiler to know the type of the expected result when 5/2 is  
evaluated.

> auto b = 5 / 2; // b is double, FP division
>
> auto c = cast(int)(5/2)); // compiler instructed to use integer division

No, the cast would apply to the result of (5/2), not the '/' operator.

> auto d = floor(5 / 2); // FP division floored by a function to int

floor returns a real, not an int. I think you were looking for roundTo!int  
or roundTo!int(floor(5/2))

> auto f = std.math.div(5, 2); // intristic that does integer division
>
> what's the rationale of not doing the above, besides C compatibility?

The rationale is that integer division is very common and is usually  
assigned back into an int, and not a real. The only issue is literals,  
which were going to be handled with polysemous values (but that got  
dropped). But 2/5.0 is really not that much overhead.



More information about the Digitalmars-d mailing list