On 3/16/2012 5:16 PM, Andrei Alexandrescu wrote:
> Not convinced. They call it specialization, and it's a powerful concept. We use
> it in std.algorithm all over the place.

I'll admit my argument may not sound convincing. But I've lived this problem for 25 years. Through trial and error, mostly error, I have found what works.

Even if the default works, it's performance may be execrable, and it may get overlooked for years until bearophile(!) posts a benchmark showing it sux. Worse, the default may not even work properly on System X. By having no default, the porter quickly finds *all* of the system dependent code sections, and has to make a decision on each one. This is good. And it is NOT a burden. I can say this from experience.

Quick test for the skeptical: find all of the default OS specific code in Phobos.

(There's no straightforward way to do it.)

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jk0ptd$29g2$1@digitalmars.com...
> On 3/16/12 8:16 PM, Daniel Murphy wrote:
>> The only time to make this decision is when implementing
>> support for a specific platform, and this pattern forces you to consider
>> each place where platform specific behaviour is required.  When doing
>> things
>> like this, 100 false positives are much faster to fix than a single false
>> negative causing wrong code/corruption.
>
> I just find it difficult to get convinced about this. Walter has often talked my ear off about this dogma and never produced a convincing argument.
>

Walter has produced arguments that have convinced a number of us. Daniel and I, at the very least. What Walter has failed to do is convince *you*, and that's a very, very different thing. Especially when he's pitted against counterarguments like "I just find it difficult to get convinced about this" ;)

On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu wrote:
> This is in the same vein: "let's avoid else".

It seems to me more like "final switch" vs. "default:".

On 3/16/12 11:50 PM, Nick Sabalausky wrote:
> Walter has produced arguments that have convinced a number of us. Daniel and
> I, at the very least. What Walter has failed to do is convince *you*, and
> that's a very, very different thing. Especially when he's pitted against
> counterarguments like "I just find it difficult to get convinced about this"
> ;)

The burden of proof is not on me, and besides I articulated my argument.

Andrei

Am Fri, 16 Mar 2012 14:37:43 -0700
schrieb Sean Kelly <sean@invisibleduck.org>:

> On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:
> 
> > Am Fri, 16 Mar 2012 12:08:01 -0700
> > schrieb Walter Bright <newshound2@digitalmars.com>:
> > 
> >> On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
> >>> Just found this, has anyone tried dmd or friends on OpenBSD?
> >>> 
> >>> http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
> >> 
> >> There was a start on an OpenBSD port, but it hasn't progressed very far. It shouldn't be hard - if someone wants to pick up the flag on this and run with it, I'd be happy to fold in the changes.
> > 
> > AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support?
> > 
> > (We have a similar problem with Android, I know for sure TLS isn't
> > supported there.)
> 
> OSX pre-Lion doesn't support __thread either, so DMD rolls its own there.  The same functionality could probably be used for OpenBSD.
> 

That's interesting. GCC does have emulated TLS as well but GCC's implementation doesn't work with the GC. I guess the dmd tls emulation is in the backend, so nothing GDC could use?

I think Walter and Andrei are both right, just about different things.

I think Walter is right that there is no such thing as a default implementation when it comes to compatibility with the host environment, and asserting is the best course of action.

I think Andrei is right that when a particular environment has some advantageous alternate implementation of a feature it can be used while leaving the default for the cases where said feature is unavailable.

Walter is concerned with compatibility, Andrei with opportunistic optimisation.

Knowing how to tell the difference is the real trick, and that is often a much harder thing to pin down. Code that potentially needs to be different on every platform should assert when the platform is unrecognised. Code which is specialised for just a few platforms and has a "known good" default can use else to provide said default. When unsure, assert is the more cautious option.

A...

On Mar 17, 2012, at 1:25 AM, Johannes Pfau <nospam@example.com> wrote:

> Am Fri, 16 Mar 2012 14:37:43 -0700
> schrieb Sean Kelly <sean@invisibleduck.org>:
> 
>> On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:
>> 
>>> Am Fri, 16 Mar 2012 12:08:01 -0700
>>> schrieb Walter Bright <newshound2@digitalmars.com>:
>>> 
>>>> On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
>>>>> Just found this, has anyone tried dmd or friends on OpenBSD?
>>>>> 
>>>>> http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
>>>> 
>>>> There was a start on an OpenBSD port, but it hasn't progressed very far. It shouldn't be hard - if someone wants to pick up the flag on this and run with it, I'd be happy to fold in the changes.
>>> 
>>> AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support?
>>> 
>>> (We have a similar problem with Android, I know for sure TLS isn't
>>> supported there.)
>> 
>> OSX pre-Lion doesn't support __thread either, so DMD rolls its own there.  The same functionality could probably be used for OpenBSD.
>> 
> 
> That's interesting. GCC does have emulated TLS as well but GCC's implementation doesn't work with the GC. I guess the dmd tls emulation is in the backend, so nothing GDC could use?

There's a bit of blackened support to denote tls data, but the rest is in library. Look at core.thread.

Pretty much. I'd expect to see:

version (linux) {
    // optimized impl
} else version (OSX) {
    version = UseDefault;
} else {
    static assert(false, "unknown platform");
}
version (UseDefault) {
    ...
}

This way, new platforms have to be evaluated, but once they are they can all share whatever common implementation is the default.

On Mar 17, 2012, at 3:31 AM, Alix Pexton <alix.DOT.pexton@gmail.DOT.com> wrote:

> I think Walter and Andrei are both right, just about different things.
> 
> I think Walter is right that there is no such thing as a default implementation when it comes to compatibility with the host environment, and asserting is the best course of action.
> 
> I think Andrei is right that when a particular environment has some advantageous alternate implementation of a feature it can be used while leaving the default for the cases where said feature is unavailable.
> 
> Walter is concerned with compatibility, Andrei with opportunistic optimisation.
> 
> Knowing how to tell the difference is the real trick, and that is often a much harder thing to pin down. Code that potentially needs to be different on every platform should assert when the platform is unrecognised. Code which is specialised for just a few platforms and has a "known good" default can use else to provide said default. When unsure, assert is the more cautious option.
> 
> A...

On Sat, Mar 17, 2012 at 7:10 AM, Sean Kelly <sean@invisibleduck.org> wrote:
> Pretty much. I'd expect to see:
>
> version (linux) {
>    // optimized impl
> } else version (OSX) {
>    version = UseDefault;

Speaking of version specification, in this particular example is version(UseDefault) only define on this module? The Language reference doesn't seem to mention anything explicitly about this. It does have the following:

"Predefined version identifiers are global, i.e. they apply to all modules being compiled and imported."

Does this mean that the opposite is true? 'version = UseDefault' is only define in the module defined.

Thanks,
-Jose

> } else {
>    static assert(false, "unknown platform");
> }
> version (UseDefault) {
>    ...
> }
>
> This way, new platforms have to be evaluated, but once they are they can all share whatever common implementation is the default.
>
> On Mar 17, 2012, at 3:31 AM, Alix Pexton <alix.DOT.pexton@gmail.DOT.com> wrote:
>
>> I think Walter and Andrei are both right, just about different things.
>>
>> I think Walter is right that there is no such thing as a default implementation when it comes to compatibility with the host environment, and asserting is the best course of action.
>>
>> I think Andrei is right that when a particular environment has some advantageous alternate implementation of a feature it can be used while leaving the default for the cases where said feature is unavailable.
>>
>> Walter is concerned with compatibility, Andrei with opportunistic optimisation.
>>
>> Knowing how to tell the difference is the real trick, and that is often a much harder thing to pin down. Code that potentially needs to be different on every platform should assert when the platform is unrecognised. Code which is specialised for just a few platforms and has a "known good" default can use else to provide said default. When unsure, assert is the more cautious option.
>>
>> A...

On 3/17/12 9:10 AM, Sean Kelly wrote:
> Pretty much. I'd expect to see:
>
> version (linux) {
>      // optimized impl
> } else version (OSX) {
>      version = UseDefault;
> } else {
>      static assert(false, "unknown platform");
> }
> version (UseDefault) {
>      ...
> }

Taking this to its logical conclusion means that _all_ code that is currently unguarded must be guarded by version (UseDefault).

Andrei