There are currently a few pull requests related to interfacing to C's long double type on Win64, most of which have been already merged:
 - https://github.com/D-Programming-Language/dmd/pull/3981
 - https://github.com/D-Programming-Language/druntime/pull/958
 - https://github.com/D-Programming-Language/dmd/pull/3990

At first glance, this solution does not seem to be very appealing to me:

 1. We need to teach everybody to not use 'real' when declaring C APIs, even though it's currently all over the place.

 2. It effectively forces everybody to make all conversions to long double explicit in their code, at least if it they want to be cross-platform compatible. As the conversion will still be implicit on all platforms other than Win64 (and potentially some GDC/LDC targets), it seems like this could turn into another size_t-style portability trap.

I guess this has already been discussed more extensively, though. I even seem to remember talking about making real equivalent to the 64 bit long double type on MSVC targets (which IIRC GDC is going to do anyway). As I've been more or less out of the loop for a while, could somebody please point me to the relevant threads/issues/DIPs/…?

Cheers,
David

On 9/15/2014 3:24 PM, David Nadlinger wrote:
>   1. We need to teach everybody to not use 'real' when declaring C APIs, even
> though it's currently all over the place.

They should use c_long_double when interfacing with C and C++.


>   2. It effectively forces everybody to make all conversions to long double
> explicit in their code,

This is due to D currently not allowing implicit conversion to a struct. It's a general issue, and should be dealt with as a general issue, as it comes up whenever a wrapped type is used.


> at least if it they want to be cross-platform
> compatible. As the conversion will still be implicit on all platforms other than
> Win64 (and potentially some GDC/LDC targets), it seems like this could turn into
> another size_t-style portability trap.

I wouldn't call it a "trap", just a minor issue that the compiler will complain about.


> I guess this has already been discussed more extensively, though. I even seem to
> remember talking about making real equivalent to the 64 bit long double type on
> MSVC targets (which IIRC GDC is going to do anyway). As I've been more or less
> out of the loop for a while, could somebody please point me to the relevant
> threads/issues/DIPs/…?

Even if we did that, it doesn't solve the issue of C++ name mangling for types that D doesn't have, such as 'long' and 'unsigned long'. Those will still need to be wrapped types.

http://forum.dlang.org/post/uhrxangvpblsadewhnck@forum.dlang.org ?

On 15 September 2014 23:24, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> There are currently a few pull requests related to interfacing to C's long
> double type on Win64, most of which have been already merged:
>  - https://github.com/D-Programming-Language/dmd/pull/3981
>  - https://github.com/D-Programming-Language/druntime/pull/958
>  - https://github.com/D-Programming-Language/dmd/pull/3990
>
> At first glance, this solution does not seem to be very appealing to me:
>
>  1. We need to teach everybody to not use 'real' when declaring C APIs, even
> though it's currently all over the place.
>
>  2. It effectively forces everybody to make all conversions to long double
> explicit in their code, at least if it they want to be cross-platform
> compatible. As the conversion will still be implicit on all platforms other
> than Win64 (and potentially some GDC/LDC targets), it seems like this could
> turn into another size_t-style portability trap.
>
> I guess this has already been discussed more extensively, though. I even seem to remember talking about making real equivalent to the 64 bit long double type on MSVC targets (which IIRC GDC is going to do anyway).

I would do it if GDC supported MSVC.  :o)

Real has /always/ been the equivalent of long double on all targets in GDC's implementation.  The GCC compiler backend doesn't really keep information about the largest float format supported by the CPU, regardless of whether or not the size of long double is smaller.

Iain.

On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:
> On 9/15/2014 3:24 PM, David Nadlinger wrote:
>>  2. It effectively forces everybody to make all conversions to long double
>> explicit in their code,
>
> This is due to D currently not allowing implicit conversion to a struct. It's a general issue, and should be dealt with as a general issue, as it comes up whenever a wrapped type is used.
>

You say 'currently'. Is there a plan to allow this, if there's no
ambiguity and if the wrapping struct defines some kind of
opImplicitCast?

On 9/16/14, 3:45 AM, Nicolas Sicard wrote:
> On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:
>> On 9/15/2014 3:24 PM, David Nadlinger wrote:
>>>  2. It effectively forces everybody to make all conversions to long
>>> double
>>> explicit in their code,
>>
>> This is due to D currently not allowing implicit conversion to a
>> struct. It's a general issue, and should be dealt with as a general
>> issue, as it comes up whenever a wrapped type is used.
>>
>
> You say 'currently'. Is there a plan to allow this, if there's no
> ambiguity and if the wrapping struct defines some kind of
> opImplicitCast?

It's on the table. -- Andrei

On Tuesday, 16 September 2014 at 14:52:13 UTC, Andrei Alexandrescu wrote:
> It's on the table. -- Andrei

sweet. Implicit casts like that are IMO evil most the time... but when doing transparent wrappers there's times when they are appropriate and I sometimes want them. (Along with multiple or templated alias this, they tackle different problems.)