On 24 January 2012 12:32, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> On 24/01/2012 10:37, Don Clugston wrote:
> <snip>
>
>> IMHO the ideal solution would be:
>> - treat size_t as a magical type (not a simple alias).
>> - allow size_t -> uint if you are in a machine-specific version statement
>> that implies 32
>> bits (eg, version(D_InlineAsm_X86), version(Win32), version(X86)).
>> - allow size_t -> ulong if you are in a version statement that implies 64
>> bits.
>> - Otherwise, disallow implicit casts.
>
> <snip>
>
> And have what rules for implicit conversions _to_ size_t?
>
> Stewart.

Any unsigned integral types with the same or smaller IntRange than size_t would be allowed, I would have thought...

ie: only ulong -> size_t needs explicit casting on 32bit systems.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 1/24/12 5:37 AM, Don Clugston wrote:
> On 20/01/12 01:25, Trass3r wrote:
>> Could we please have at least a warning if code isn't compatible with
>> 64Bit?
>> It's really annoying to test out some code and having to fix a bunch of
>> stupid uint->size_t bugs just because the author is still on a 32 bit
>> machine.
>>
>> Is that feasible?
>
>
> IMHO the ideal solution would be:
> - treat size_t as a magical type (not a simple alias).
> - allow size_t -> uint if you are in a machine-specific version
> statement that implies 32 bits (eg, version(D_InlineAsm_X86),
> version(Win32), version(X86)).
> - allow size_t -> ulong if you are in a version statement that implies
> 64 bits.
> - Otherwise, disallow implicit casts.
>
> Incidentally this was a motivation for the 'one-definition rule' that I
> proposed for version statements: it means the compiler can easily
> identify which versions imply machine-specific.

I think the ODR for version is right on the money. FWIW I also think the strategy you sketch would work (it's similar to gcc's), but I'd say - let's not implement this. It's a "nice to have" thing but doesn't add much power, and doesn't remove a large annoyance.

Andrei