On Mar 17, 2012, at 6:00 PM, "Bernard Helyer" <b.helyer@gmail.com> wrote:

> On Sunday, 18 March 2012 at 00:53:17 UTC, Walter Bright wrote:
>> On 3/17/2012 5:40 PM, Sean Kelly wrote:
>>> In truth it would be
>>> 
>>> else version (Posix)
>>> 
>>> Anyway, which isn't the bare else Walter was advising against.
>> 
>> And is Posix really predictably compatible across diverse systems?
> 
> If you restrict yourself to the LCD stuff, yeah mostly. The trouble is you get various nicer ways of doing things that aren't (as) portable.

For what it's worth, core.sys.posix is based on the OpenGroup spec. I suppose that's the LCD.

On Sunday, 18 March 2012 at 04:04:30 UTC, Sean Kelly wrote:
> On Mar 17, 2012, at 6:00 PM, "Bernard Helyer" <b.helyer@gmail.com> wrote:
>
>> On Sunday, 18 March 2012 at 00:53:17 UTC, Walter Bright wrote:
>>> On 3/17/2012 5:40 PM, Sean Kelly wrote:
>>>> In truth it would be
>>>> 
>>>> else version (Posix)
>>>> 
>>>> Anyway, which isn't the bare else Walter was advising against.
>>> 
>>> And is Posix really predictably compatible across diverse systems?
>> 
>> If you restrict yourself to the LCD stuff, yeah mostly. The trouble is you get various nicer ways of doing things that aren't (as) portable.
>
> For what it's worth, core.sys.posix is based on the OpenGroup spec. I suppose that's the LCD.

Yeah, I've not had problems with the OG stuff.

On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu wrote:
>>> This seems to accomplish little more than "well I didn't use else".
>>>
>>> Again: what exactly is wrong with specialization?
>>>
>>
>> The advantage is, that when you write the code, you have _no idea_ what
>> platform/os it might need to run on in the future.  You _cannot_ know which
>> version is most appropriate for _all_ new platforms, or even if any of them
>> will work at all.
>
> Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.

version(PlatformX)
{
    return superfastgetchar();
}
else
{
    return getchar();
}

Later on, we add support for PlatformY, which also supports superfastgetchar(). If you write code as above then no one will notice. It will just happily use getchar() and suffer because of it. If you static assert on new platforms then it forces you to look at the code for each new platform added and think about what version would be best.

As Walter said, you can't know what version will be most appropriate for all new platforms.

On Saturday, 17 March 2012 at 00:16:39 UTC, 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 think having good-enough defaults works well for std.algorithm, simply because requiring explicit versions of everything would be tedious and error-prone. For platform-dependent code, I think requiring explicit versions is less tedious due to the relative infrequency of having to add a new platform.

It's purely a matter magnitude. If std.algorithm only had to support say, five types, with a new type added maybe once a year, I think requiring explicit versions of every parameterized function would be a good idea, too. It forces you to think about things.

On Sunday, 18 March 2012 at 18:09:42 UTC, Peter Alexander wrote:
> On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu wrote:
>>>> This seems to accomplish little more than "well I didn't use else".
>>>>
>>>> Again: what exactly is wrong with specialization?
>>>>
>>>
>>> The advantage is, that when you write the code, you have _no idea_ what
>>> platform/os it might need to run on in the future.  You _cannot_ know which
>>> version is most appropriate for _all_ new platforms, or even if any of them
>>> will work at all.
>>
>> Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.
>
> version(PlatformX)
> {
>     return superfastgetchar();
> }
> else
> {
>     return getchar();
> }
>
> Later on, we add support for PlatformY, which also supports superfastgetchar(). If you write code as above then no one will notice. It will just happily use getchar() and suffer because of it. If you static assert on new platforms then it forces you to look at the code for each new platform added and think about what version would be best.
>
> As Walter said, you can't know what version will be most appropriate for all new platforms.

It should be possible to eat the cake and still have it... even if warnings normally are frowned upon(with good reason), using warnings for this would allow the benefits from both "camps"...

It would allow a painless "prototype porting" for new operating systems which are similar, yet... even if it does work, at a later point one would still have to go through all the version statements and either silencing the warning, or selecting the optimized path.

On 3/18/2012 11:28 AM, Tove wrote:
> It should be possible to eat the cake and still have it... even if warnings
> normally are frowned upon(with good reason), using warnings for this would allow
> the benefits from both "camps"...
>
> It would allow a painless "prototype porting" for new operating systems which
> are similar, yet... even if it does work, at a later point one would still have
> to go through all the version statements and either silencing the warning, or
> selecting the optimized path.


I know that we've all been trained to avoid copypasta, and have an instinctive "ick" factor when seeing it.

But it really is not painful to do a little copypasta for the system versions, nor does there need to be any new language features for this.