Andrei's std.path review

[Lars T. Kyllingstad]

On Sat, 13 Aug 2011 09:26:45 -0500, Andrei Alexandrescu wrote:

> On 8/13/11 7:20 AM, Lars T. Kyllingstad wrote:
>> On Thu, 11 Aug 2011 00:27:54 -0700, Jonathan M Davis wrote:
>>> On Thursday, August 11, 2011 07:10:08 Lars T. Kyllingstad wrote:
>>>> On Wed, 10 Aug 2011 12:37:01 -0600, Andrei Alexandrescu wrote:
>>>>> * filenameCharCmp and filenameCmp ->  why long and not int?
>>>>
>>>> filenameCharCmp() returns a-b, and since a and b are dchars, the
>>>> corresponding signed type is long.  filenameCmp() returns long
>>>> because filenameCharCmp() does.
>>>
>>> I'd argue that you should just cast it to int and return int. All the
>>> various compare functions promise is whether the return value is less
>>> than, equal to, or greater than 0. Relying on the exact value is
>>> wrong. And normally such functions return int. So, I don't see any
>>> reason why these shouldn't be change to return int.
>>
>> But what do we gain by making it an int?  long just seems more natural
>> in this case, IMO.
> 
> Unicode characters range in between 0 through 1,114,111. So the most
> natural type of the difference is int.
> 
> This would be the first time I'm seeing an API returning a ternary value
> as a long.
> 
> (Also, 64-bit machines can operate on two 32-bit integrals
> simultaneously (literally) so 32-bit integrals may be faster. Probably
> not a material advantage.)

All right, you have convinced me.  int it is. :)

-Lars