On Tuesday, 4 June 2013 at 00:19:39 UTC, Manu wrote:
On 4 June 2013 03:06, David Nadlinger <c...@klickverbot.at>
wrote:
On Monday, 3 June 2013 at 16:25:24 UTC, Manu wrote:
You won't break every single method, they already went
through that
recently when override was made a requirement. […] A much
smaller number than the breakage
which was gladly accepted recently. […] how did the override
change ever get accepted […]
It appears as if either you have a interesting definition of
"recently",
or you are deliberately misleading people by bringing up that
point over
and over again.
According to
http://dlang.org/changelog.**html<http://dlang.org/changelog.html>,
omitting "override" produced a warning since D 2.004, which
was released
back in September 2007! Granted, it was only actually turned
from a
deprecation warning into an actual deprecation in 2.061 (if my
memory
serves me right), but it's mostly a flaw in the handling of
that particular
deprecation that it stayed at the first level for so long. The
actual
language change was made – and user-visible – almost six (!)
years ago,
which is a lot on the D time scale.
Ah, sorry, I didn't realise that. I only recall conversations
arising when
it actually became deprecated, and people had to change their
code.
You are also ignoring the fact that in contrast to requiring
"override",
there is no clean deprecation path for your proposal, at least
as far as I
can see: Omitting the keyword started out as a warning, and
IIRC still is
allowed when you enable deprecated features via the compiler
switch. How
would a similar process look for virtual-by-default? As far as
am isolated
module with only a base class is concerned, this is not
question of valid
vs. invalid code, but a silent change in language semantics.
The exact same path is available if you want to apply it:
1. Introduce 'virtual', create a warning when override is used
on a
function not marked. Functions remain virtual-by-default for
the time being.
2. At some later time, deprecate it (collecting the stragglers
who haven't
updated their code yet). Functions remain virtual-by-default.
3. Pull the pin. Functions become final by default, and
virtuals should
have already been marked during the previous periods.
I'm not sure I follow your point about an isolated base class.
In the event you have an isolated base class, where no classes
are derived
from it, then it's not actually polymorphic, so why should it's
methods be
virtual?
In the event that it's a base-class-in-waiting, then it's true
that you'll
notice a compile error at a later time when you do eventually
derive from
it, but that's not really a breaking change, and it's almost in
line with
my points about explicit consideration; each method that
receives the
virtual keyword would take a moments consideration from the
author as to
whether it's actually correct/safe to be overriding that method
or not. Ie,
the momentary compile error where you write 'virtual' gives you
the
opportunity for that thought.
From DConf I know that you are actually are a friendly,
reasonable person,
but in this discussion, you really come across as a
narrow-minded zealot to
me. So, please, let's focus on finding an actually practical
solution!
But this is a practical solution. The only counter-proposal
I've heard is
Andrei's 'all methods use ufcs' idea, but I think that one
would be a much
harder sell to the community. I'm certainly not convinced.
It's really quite trivial, it's orthogonal with usage of
override, it's
more efficient, less error prone (which I have demonstrated
happen all the
time), enhances interoperation with C++, and it should even
improve code
fragility too (ie, people possibly overriding methods that are
unsafe to
override where the author never considered the possibility).
Is there a reason this change offends you enough to call me
names? Or can
you at least tell how I'm being narrow-minded?
For example, if we had !pure/!nothrow/!final or something along
the lines,
just mandate that "final:" is put at the top of everything in
your style
guide (easily machine-enforceable too) – problem solved?
That's not quite the case though. Even if I could retrain
internal staff to
start doing that everywhere, you've potentially blocked access
to a whole
bunch of libraries because library authors don't follow our
style guide.
We suffer this in C++ all the time (see my many rant's about
unnecessarily
spending my life re-inventing wheels). Anything to make subtle
pushes that
improve usability/portability of libraries can only be a good
thing.
Especially when library authors generally don't specifically
consider all
usage environments. The language can assist some some extent.
It's also precisely the same amount of work to type 'virtual:'
(and it's
the lesser common case to want to), except taking that angle
enables the
advantages I mention above, and also tends to force people to
give a
moments consideration to their API design/intent wrt virtual.
Remember going virtual is a one-way trip. It can never be
undone, which
makes it a terribly dangerous default state.
And maybe it would even catch on in the whole D community and
lead to a
language change in D3 or a future iteration of the language.
David
+1