On Friday, 14 March 2014 at 18:06:47 UTC, Iain Buclaw wrote:

>     else version (OSX) {
>         version (PPC)
>            iSomeWackyFunction();
>         else
>            SomeWackyFunction();   // In hope there's no other Apple hardware.

There's also ARM, ARM64, x86 32bit and PPC64.

--
/Jacob Carlborg

On 15 Mar 2014 09:44, "Jacob Carlborg" <doob@me.com> wrote:
>
> On Friday, 14 March 2014 at 18:06:47 UTC, Iain Buclaw wrote:
>
>>     else version (OSX) {
>>         version (PPC)
>>            iSomeWackyFunction();
>>         else
>>            SomeWackyFunction();   // In hope there's no other Apple
hardware.
>
>
> There's also ARM, ARM64, x86 32bit and PPC64.
>
> --
> /Jacob Carlborg

Wonderful - so the OSX bindings in druntime are pretty much in a dia state for someone who wishes to port to a non-X86 architecture?  I know the BSD and Solaris code needs fixing up and testing.

On 15 March 2014 18:50, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "Walter Bright"  wrote in message news:lg0vtc$2q94$1@digitalmars.com...
>
>
>  I find it peculiar to desire a 'final accessor'. After all,
>>
>>      class C {
>>          int x;
>>          final int getX() { return x; } <= what the heck is this function
>> for?
>>      }
>>
>
> Yeah, it's stupid, but people do it all over the place anyway.


Religiously. They're taught to do this in books and at university,
deliberately.
Seriously though, there are often reasons to put an interface in the way;
you can change the implementation without affecting the interface at some
later time, data can be compressed or stored in an internal format that is
optimal for internal usage, or some useful properties can be implied rather
than stored explicitly. Programmers (reasonably) expect they are inlined.

For instance framesPerSecond() and timeDelta() are the reciprocal of
eachother, only one needs to be stored.
I also have very many instances of classes with accessors to provide
user-facing access to packed internal data, which may require some minor
bit-twiddling and casting to access. I don't think this is unusual, any
programmer is likely to do this. empty(), length(), front(), etc are
classic examples where it might not just return a variable directly.
Operator overloads... >_<

 It's a major breaking change. It'll break nearly every D program out there
>> that uses classes.
>>
>
> This is nonsense.  I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!
>
> Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'.  Druntime needed 25.
>
> We don't even need to follow the usual 6-months per stage deprecation - We could leave it as a warning for 2 years if we wanted!
>
> Grepping for class declarations and sticking in "virtual:" is as trivial as a fix can possibly be.
>

My game that I'm hacking on at the moment has only 2 affected classes. The
entire game is OO. Most virtuals are introduced by interfaces.
So with that in mind, it's not even necessarily true that projects that use
classes will be affected by this if they make use of interfaces (I
certainly did at Remedy, exclusively).

Phobos is a standard library, surely it's unacceptable for phobos calls to
break the optimiser? Consider std.xml for instance; 100% certain to appear
in hot data crunching loops.
What can be done about this? It can't be fixed, because that's a breaking
change. Shall we document that phobos classes should be avoided or factored
outside of high frequency code, and hope people read it?

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.133.1394879414.23258.digitalmars-d@puremagic.com...

> Phobos is a standard library, surely it's unacceptable for phobos calls to break the optimiser?
> Consider std.xml for instance; 100% certain to appear in hot data crunching loops.
> What can be done about this? It can't be fixed, because that's a breaking change. Shall we
> document that phobos classes should be avoided or factored outside of high frequency code, and
> hope people read it?

I think std.xml should be avoided for other reasons... 

On Saturday, 15 March 2014 at 08:50:00 UTC, Daniel Murphy wrote:
> This is nonsense.  I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!
>
> Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'.  Druntime needed 25.
>
> We don't even need to follow the usual 6-months per stage deprecation - We could leave it as a warning for 2 years if we wanted!
>
> Grepping for class declarations and sticking in "virtual:" is as trivial as a fix can possibly be.

When virtual keyword was introduced in Github master I immediately went to add a bunch of "virtual" in my projects... only to find myself done after few minutes.

I see some irony in the fact that if classes are made final-by-default, removing all the unnecessary "final" attributes would be an order of magnitude longer task.

Daniel Murphy:

> This is nonsense.  I tried out the warning on some of my projects, and they required ZERO changes - because it's a warning!
>
> Phobos requires 37 "virtual:"s to be added - or just change the makefile to use '-wi' instead of '-w'.  Druntime needed 25.

Andrei has decided to not introduce "final by default" because he thinks it's a too much large breaking change. So your real world data is an essential piece of information to perform an informed decision on this topic (so much essential that I think deciding before having such data is void decision). So are you willing to perform your analysis on some other real D code? Perhaps dub?

Bye,
bearophile

> So are you willing to perform your analysis on some other real D code? Perhaps dub?

Or vibe?

Bye,
bearophile

Am Fri, 14 Mar 2014 13:48:40 +1000
schrieb Manu <turkeyman@gmail.com>:

> I feel like this was aimed at me, and I also feel it's unfair.
> 
> If you recall back to the first threads on the topic, I was the absolute
> minority, almost a lone voice. Practically nobody agreed, infact, there was
> quite aggressive objection across the board, until much discussion about it
> has passed.
> I was amazed to see in this thread how many have changed their minds from
> past discussions. Infact, my impression from this thread is that the change
> now has almost unanimous support, and by my recollection, many(/most?) of
> those people were initially against.
> 
> To say this is a small vocal faction is unfair (unless you mean me
> personally?). A whole bunch of people who were originally against, but were
> convinced by argument and evidence is not a 'faction' with an agenda to
> intimidate their will upon leadership.
> I suspect what seems strange to the participants in this thread, that
> despite what eventually appears to have concluded in almost unanimous
> agreement (especially surprising considering the starting point years
> back!), is the abrupt refusal.
> That's Walter's prerogative I guess... if he feels that strongly about it,
> then I'm not going to force the issue any more.
> 
> I am surprised though, considering the level of support for the change
> expressed in this thread, which came as a surprise to me; it's the highest
> it's ever been... much greater than in prior discussions on the topic.
> You always say forum participation is not a fair representation of the
> community, but when the forum representation is near unanimous, you have to
> begin to be able to make some assumptions about the wider communities
> opinion.

Me too, I got the impression, that once the library authoring issue was on the table, suddenly everyone could relate to final-by-default and the majority of the forum community found it to be a reasonable change.

For once in a decade it seemed that one of the endless discussions reached a consensus and a plan of action: issue a warning, then deprecate. I was seriously relieved to see an indication of a working decision making process initiated by the forum community. After all digitalmars.D is for discussing the language.

Then this process comes to a sudden halt, because Walter gets negative feedback about some unrelated braking change and Andrei considers final-by-default good, but too much of a breaking change for what it's worth. Period. After such a long community driven discussion about it.

One message that this sends out is that a proposal, even with almost complete lack of opposition, an in-depth discussion, long term benefits and being in line with the language's goals can be turned down right when it is ready to be merged.

The other message is that the community as per this forum is not representative of the target audience, so our decisions may not be in the best interest of D. Surprisingly though, most commercial adapters that ARE here except for one, have no problem with this announced language change for the better.

I neither see a small vocal faction intimidating (wow!) the leadership, nor do I see a dictate of the majority. At least 2 people mentioned different reasons for final-by-default that convinced most of us that it positively changes D. ...without threats like "we won't use D any more if you don't agree".

Paying customers including Facebook can have influence
on what is worked on, but D has become a community effort and
freezing the language for the sake of creating a stable target
for them while core language features are still to be
finalized (i.e. shared, allocation) is not convincing.

-- 
Marco

On Sat, 15 Mar 2014 04:08:51 -0400, Daniel Kozák <kozzi11@gmail.com> wrote:

> deadalnix píše v Pá 14. 03. 2014 v 22:25 +0000:
>> On Friday, 14 March 2014 at 22:06:13 UTC, Daniel Kozák wrote:
>> > First I think have something like
>> >
>> > @disable(final,nothrow) would be the best way, but than I think
>> > about it
>> > and realize that final(false) is much more better.
>> >
>>
>> If I may, final!false . We have a syntax for compile time
>> parameter. Let's be consistent for once.
>>
>> The concept is solid and is the way to go. DIP anyone ?
>
> final!true
> final!(true)
> final(!true) oops :)

If final!true is valid, final(true) and final(!true) will not be.

-Steve

Am Fri, 14 Mar 2014 19:29:27 +0100
schrieb Paulo Pinto <pjmlp@progtools.org>:

> That is why the best approach is to have one module per platform specific code, with a common interface defined in .di file.

Which is basically what Iain proposed for druntime. Then the thread got hijacked and talked about three different issues in the end. Walter answered to the other issues, but not to Iain's original request, Andrei agreed with Walter, the discussion ended, pull request closed and nothing will happen ;-)


https://github.com/D-Programming-Language/druntime/pull/731 https://github.com/D-Programming-Language/druntime/pull/732

I think we'll have to revisit this at some point, but right now there's other stuff to be done...