On 7/3/2014 2:43 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Would you use D for building software to ship with hardware appliances?

Yes.


> I would not.

The issues you presented are subjective and a matter of opinion. Regardless of the state of D, I'm not the type who wilts at an issue or two - I work around it. And so does everyone else who does production work.

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 :-)

On 7/3/2014 1:30 PM, Tofu Ninja wrote:
> On Thursday, 3 July 2014 at 19:47:32 UTC, Walter Bright wrote:
>> On 7/3/2014 8:36 AM, Sean Kelly wrote:
>>>> Per the D spec, 'real' will be the longest type supported by the native
>>>> hardware.
>>
>> It's not necessary that real be long double - but it is necessary that long
>> double be callable from D.
>>
>> Case in point: long double on Win64 is accessible with D's "double", but D
>> also supports 80 bit "real".
>
> That makes it seem like we are compatible by accident rather than by design.

??

I see nothing wrong with it, and it was on purpose.

On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote:
> 
> The issues you presented are subjective and a matter of opinion. Regardless of the state of D, I'm not the type who wilts at an issue or two - I work around it. And so does everyone else who does production work.
>
> 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 :-)

Well said, and that's exactly how things tend to works.
---
Paolo

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

On Thursday, 3 July 2014 at 14:26:51 UTC, Iain Buclaw via Digitalmars-d wrote:
> It's also a handy coincidence that for many platforms the targets
> largest supported FP and *double* type happen to be the same too.

Out of curiosity, how is C "long double" interpreted on those platforms?  Just doesn't exist, or is interpreted as the same as double?

What's concerning me here is that you've posted at least one example platform where the C long double is _not_ the same as the largest FP type.

Now, it makes sense to me that the spec _could_ be, "real == largest hardware-supported FP type", and it makes sense that the spec could be, "real == C long double for the platform".  But it seems quite apparent that it can't mean both, and that there needs to be a firm decision about which we want it to be.

On Thursday, 3 July 2014 at 00:03:47 UTC, Walter Bright wrote:
> On 7/2/2014 3:15 PM, Sean Kelly wrote:
>> On Wednesday, 2 July 2014 at 21:44:17 UTC, Walter Bright wrote:
>>> C long double == D real for 32 and 64 bit OSX, Linux, and FreeBSD.
>>
>> And it's 'double double' on PPC and 128 bit quad on SPARC.
>> Assuming D targets those platforms, what will be the behavior
>> there?
>
> Per the D spec, 'real' will be the longest type supported by the native hardware.


This is the problem. If that is the case, it is USELESS.
We *must* change that definition.

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.

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?

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.

"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.

> 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, but luckily relatively few interfaces actually use long double. 

On 4 Jul 2014 10:40, "Joseph Rushton Wakeling via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 3 July 2014 at 14:26:51 UTC, Iain Buclaw via Digitalmars-d
wrote:
>>
>> It's also a handy coincidence that for many platforms the targets largest supported FP and *double* type happen to be the same too.
>
>
> Out of curiosity, how is C "long double" interpreted on those platforms?
 Just doesn't exist, or is interpreted as the same as double?
>

Same as double.

> What's concerning me here is that you've posted at least one example
platform where the C long double is _not_ the same as the largest FP type.
>
> Now, it makes sense to me that the spec _could_ be, "real == largest
hardware-supported FP type", and it makes sense that the spec could be, "real == C long double for the platform".  But it seems quite apparent that it can't mean both, and that there needs to be a firm decision about which we want it to be.

It's whatever you configure it to be.

Essentially, I want to give porters maximum flexibility on this.

Iain.

On 4 Jul 2014 13:10, "Daniel Murphy via Digitalmars-d" < digitalmars-d@puremagic.com> 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.
>

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

>
>> 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, but luckily relatively few
interfaces actually use long double.

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

On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote:
> The issues you presented are subjective and a matter of opinion.

Well, one has to agree on a definition for a start! :)

> If you sit around waiting for arbitrary perfection, you'll never get any work done.

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.