Ola Fosheim Grøstad:

> If the D maintainers don't care about reaching a stable state, at the expense of scope and features,

Don't be silly, D devs care a lot about reaching stability, fixing bugs, etc.

Bye,
bearophile

"Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.3265.1404477916.2907.digitalmars-d@puremagic.com...

> FP types are fixed.  float is 32bit, double 64bit.

That's 2/3.

> What 's the mangling problem with long double? There's only *one* long double.

long double may not be the same size as D's real, eg in msvc it's 64-bit. You can still still call these functions from D using double in C, but the mangling will not match in C++.

On 4 July 2014 14:01, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> "Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.3265.1404477916.2907.digitalmars-d@puremagic.com...
>
>
>> FP types are fixed.  float is 32bit, double 64bit.
>
>
> That's 2/3.
>
>
>> What 's the mangling problem with long double? There's only *one* long double.
>
>'
> long double may not be the same size as D's real, eg in msvc it's 64-bit. You can still still call these functions from D using double in C, but the mangling will not match in C++.
>

You're confusing long double with size_t.  I did a cursory look up msvc++ mangling, and long double is always 'O'.  The itanium spec says that long double is 'e' - unless 128bits in which case it is 'g'.

Iain.

"Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.3268.1404486824.2907.digitalmars-d@puremagic.com...

> You're confusing long double with size_t.  I did a cursory look up
> msvc++ mangling, and long double is always 'O'.  The itanium spec says
> that long double is 'e' - unless 128bits in which case it is 'g'.

Yes, so msvc++ has two 64-bit floating types with different manglings, and D has one.  D does not have a type that can be used to match long double's mangling with msvc. 

On 4 July 2014 17:31, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Iain Buclaw via Digitalmars-d"  wrote in message news:mailman.3268.1404486824.2907.digitalmars-d@puremagic.com...
>
>
>> You're confusing long double with size_t.  I did a cursory look up msvc++ mangling, and long double is always 'O'.  The itanium spec says that long double is 'e' - unless 128bits in which case it is 'g'.
>
>
> Yes, so msvc++ has two 64-bit floating types with different manglings, and D has one.  D does not have a type that can be used to match long double's mangling with msvc.

No, msvc++ has one mangle type.  Itanium has two, but you're never going to run into a situation where there's a conflict because long double can't be both 80bit and 128bit at the same time!

On 7/4/2014 1:37 AM, Max Samukha wrote:
> On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote:
>
>>
>> If you sit around waiting for arbitrary perfection, you'll never get any work
>> done. I don't care that my truck has dings in it, either, it's a truck and
>> it's useful for what I need it for :-)
>
> Even though a Tesla is of no more use than your old ugly truck, I still favor
> the former. :P

You wouldn't use a Tesla for hauling!

On 7/4/2014 5:48 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I pick the most stable tool for the job. Meaning I usually end up with C,
> conservative use of C++, Python 2.7, Javascript, SQL or XSLT… :-P Rarely D and
> occasionally Dart (which isn't particularly stable either and is rejected
> beacuase of it) and Php (which is pretty stable).
>
> It's a matter of priority. If the D maintainers don't care about reaching a
> stable state, at the expense of scope and features, then it will never be the
> best tool for the job. I regret that.

We care a great deal about that.

C++, etc., is a much harder tool to get work done with. You'd have to judge that difficulty and work increase against the dealing with imperfections in D. It's a clear win for D.

On 7/4/2014 3:38 AM, Don wrote:
> What is "the longest type supported by the native hardware"? I don't know what
> that means, and I don't think it even makes sense.

Most of the time, it is quite clear.


> For example, Sparc has 128-bit quads, but they only have partial support.
> Effectively. they are emulated. Why on earth would you want to use an emulated
> type on some machines, but not on others?

Emulation is not native support.


> Perhaps the intention was "the largest precision you can get for free, without
> sacrificing speed" then that's not clearly defined. On x86-32, that was indeed
> 80 bits. But on other systems it doesn't have an obvious answer.
> On x86-64 it's not that simple. Nor on PPC or Sparc.

Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X.

I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement.

On 7/4/2014 5:06 AM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:lp26l3$qlk$1@digitalmars.com...
>
>> Per the D spec, 'real' will be the longest type supported by the native hardware.
>
> So if you were targeting a processor with only soft-float real would be
> undefined?  Fixing the widths of the integers was a great idea, and we really
> should have done the same with the floating point types.  We could easily have a
> library alias for what real currently means.

Again, I expect the implementor for Platform X to be able to make a solid judgement on what to do for that platform that makes the most sense.


>> Not only that, a marquee feature of D is interoperability with C. We'd need an
>> AWFULLY good reason to throw that under the bus.
> Unfortunately it's a useless definition for portable interop with C++.  real
> needs to always match the size and mangling of long double unless you want to
> stick workarounds all over the bindings.  We have related problems with
> char/char/char and long/longlong/size_t,

Such problems disappear when common sense is applied.


> but luckily relatively few interfaces actually use long double.

I really do not understand what the big problem is. It's trivial to interface with C code on Linux that accepts long doubles on all platforms D currently supports.

On 7/4/2014 6:01 AM, Daniel Murphy wrote:
> long double may not be the same size as D's real, eg in msvc it's 64-bit. You
> can still still call these functions from D using double in C, but the mangling
> will not match in C++.


You are correct in that VC++ mangles double as 'N' and long double as 'O' but both are implemented as doubles.

This means that:

    void foo(long double d);

is callable from D if it is compiled as C, but not as C++.

This is not a language lawyer problem, as D isn't guaranteed to support all C++ mangling. As a practical problem, it would be pretty rare (since such code usually provides double overloads), and if it still was a problem a bit of adapter C++ code (a 1 liner) can be written.