On 3/13/2014 6:23 AM, Daniel Murphy wrote:
> This is one of the few areas where D is idealistic instead of pragmatic.

Nope. It's a very pragmatic decision.


> This reminds me of banning goto and multiple returns because 'structured
> programming' prevents goto spaghetti madness.  As always, it simply forces the
> programmer to jump through more hoops to get what they want.

I've seen some of those hoops programmers have done to get that behavior in D, and it resulted in just what I predicted - confusing bugs due to wacky dependencies between modules.

Bluntly, if your code requires more than version(Feature) you are doing it wrong.

I haven't yet seen an example of boolean version expressions that made the code clearer, simpler, or more maintainable than version(Feature).

I've seen endless examples of boolean version expressions that are a rat's nest of unmaintainable, buggy, confusing garbage. I've made a major effort to remove all that garbage from dmd's source code, for example, and am very pleased with the results. There's still some in druntime that I wish to get refactored out.

And yes, I'm pretty opinionated about this :-)

On 3/12/2014 11:31 PM, Nick Sabalausky wrote:
> PHP is a perfect example of why language-altering flags is a very bad path to
> start heading down. (Granted, the problem is *vastly* worse in an interpreted
> language than a compiled one, but still.)


There are examples with C and C++ compilers, too. My most unfavorite is the one that sets the signedness of 'char'.

On 3/13/2014 1:43 AM, Don wrote:
> The worst breaking change in D2, by far, is the prevention of array stomping.
>
> After that change, our code still runs, and produces exactly the same results,
> but it is so slow that it's completely unusable. This one of the main reasons
> we're still using D1.

I didn't know this. I'd like more details - perhaps I can help with how to deal with it.

13-Mar-2014 21:52, monarch_dodra пишет:
> On Thursday, 13 March 2014 at 15:57:22 UTC, Andrei Alexandrescu wrote:
>> At a level it's clear it's not a matter of right or wrong but instead
>> a judgment call, right? Successful languages go with either default.
>>
>> Andrei
>
> For what it's worth, "education" could help solve this problem: For
> example, "people" where surprised by the context pointer in nested
> structs, and now (I think), it is (or will become) second nature to
> always type:
>
> static struct S
> {...}
>
> Heck, I even do it for my global structs too now.
>
> So maybe the issue could be solved by educating to always type (by
> default):
>
> final class A
> {...}

Not the same as `final:` inside - the above just means you can't inherit from A. Funnily enough any new methods in A would still be virtual even if nothing can inherit from it!

-- 
Dmitry Olshansky

On 3/13/14, 12:38 PM, Dmitry Olshansky wrote:
> Not the same as `final:` inside - the above just means you can't inherit
> from A. Funnily enough any new methods in A would still be virtual even
> if nothing can inherit from it!

Looks like we could improve on this. Is there an enhancement request available?

Andrei

13-Mar-2014 23:40, Andrei Alexandrescu пишет:
> On 3/13/14, 12:38 PM, Dmitry Olshansky wrote:
>> Not the same as `final:` inside - the above just means you can't inherit
>> from A. Funnily enough any new methods in A would still be virtual even
>> if nothing can inherit from it!
>
> Looks like we could improve on this. Is there an enhancement request
> available?
>

None that I know of.

P.S. I have a strong distaste to the way OOP is currently designed in D anyway. No, I don't propose to change it.

-- 
Dmitry Olshansky

On Thu, 13 Mar 2014 15:38:19 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 13-Mar-2014 21:52, monarch_dodra пишет:

>> final class A
>> {...}
>
> Not the same as `final:` inside - the above just means you can't inherit from A. Funnily enough any new methods in A would still be virtual even if nothing can inherit from it!
>

What? Where's that low hanging fruit again?

-Steve

On 3/13/14, 12:49 PM, Dmitry Olshansky wrote:
> 13-Mar-2014 23:40, Andrei Alexandrescu пишет:
>> On 3/13/14, 12:38 PM, Dmitry Olshansky wrote:
>>> Not the same as `final:` inside - the above just means you can't inherit
>>> from A. Funnily enough any new methods in A would still be virtual even
>>> if nothing can inherit from it!
>>
>> Looks like we could improve on this. Is there an enhancement request
>> available?
>>
>
> None that I know of.

Just played with some code a bit, turns out at least gdc inlines calls for final classes appropriately: http://goo.gl/oV8EYu. What would be a reliable way to detect that a vtable entry is generated?

> P.S. I have a strong distaste to the way OOP is currently designed in D
> anyway. No, I don't propose to change it.

I take it that overridable by default is part of it. What other things are not to your liking?


Andrei

On Thursday, 13 March 2014 at 18:03:42 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> There must be a way to convey that a decision has been made. It is
>> understood it won't please everybody, just like going the other way
>> won't please everybody. Please let me know what that way is.
>
> Voting.

Good programming languages have a coherent design, orthogonal features, a clean philosophy, approach... they subscribe to chosen programming models such as procedural, functional, message-passing, garbage collected, dynamically typed, strongly typed.... as the designer intended. Having a 'they who shout the loudest win' or even a voting system destroys that coherency and uniform philsophy IMHO. I don't bother with C++ because I read Herb Sutter's GOTW column from time and time and think to myself "I don't want to need to know all these very subtle issues and gotchas in my programming language". The syntax etc. of C++ I can cope with. Now, I think that Andrei and Walter are D's best chance to shepherd D away from the C++ gotcha morass. Voting on features to change / add would throw D into it. In my view adding features is particularly pernicious as they complicate the language in non-orthogonal ways leading to the need to know a broader and more complex language than necessary.

On 3/13/14, 11:37 AM, Paolo Invernizzi wrote:
> As I've stated, it is not about the single decision, I don't care about
> final vs virtual in our code. it's about the whole way that "planned
> improvement" changes to the language are managed.

Got it, thanks.

> What I was meaning is: why the past mega-thread about virtual vs final
> (that I don't care about!) that seemed (to me!) that placed a concrete
> direction goal was (to me!) scraped like a thunder in clean sky.
>
> Where's the discussion why "it turned out to be not enough"?
>
> What scares me (as a company using the language) was that I wasn't able
> to "grasp" that fact in forum till now.
>
> So, that could also happen to *other* aspect of the language that a care
> for my business, without even having the ability do discuss about the
> motivation of a decision.
>
>> There must be a way to convey that a decision has been made. It is
>> understood it won't please everybody, just like going the other way
>> won't please everybody. Please let me know what that way is.
>
> Again, the whole point was that it seemed to me that a decision was
> taken in that famous thread.
>
> My feedback, take it as you want Andrei, it is that such behaviours are
> a way more scaring that the hole point of managing a "planned" (again!)
> language change.

Understood. That's one angle. The other angle is that a small but vocal faction can intimidate the language leadership to effect a large breaking change that it doesn't believe in.

Also let's not forget that a bunch of people will have not had contact with the group and will not have read the respective thread. For them -- happy campers who get work done in D day in and day out, feeling no speed impact whatsoever from a virtual vs. final decision -- we are simply exercising the brunt of a deprecation cycle with undeniable costs and questionable (in Walter's and my opinion) benefits.


Andrei