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
