On Friday, 13 June 2014 at 03:52:00 UTC, Andrei Alexandrescu wrote:
> On 6/12/14, 8:49 PM, Nick Sabalausky wrote:
>> On 6/12/2014 11:13 PM, Andrei Alexandrescu wrote:
>>> On 6/12/14, 7:26 PM, Daniel Murphy wrote:
>>
>>>> It
>>>> 1. allows escaping final, which we can't do without it or an equivalent
>>>> 2. does exactly what everybody expects
>>>> 3. is already implemented
>>>> 4. looks much nicer than your proposal
>>>>
>>>> Why not just leave it in?  I'm already using it, and it makes
>>>> extern(C++) classes MUCH more readable (ie DDMD)
>>>
>>> Please no new keyword for what can be done already. It's not
>>> proportional response.
>>>
>>
>> AFAIK, escaping final *can't* be done.
>
> It can be worked around. -- Andrei

Yes, it can be done. I am able to do something like this:

class A
{
	mixin(Virtual!A);

final:
	@Overridable()
	void method(this M)(int x) {
		writeln("virtual A");
	}
}

class B : A
{
	mixin(Virtual!B);
final:
	@Override() void method(this M)(int x) {
		writeln("virtual B");
	}
}

class C : B
{
final:
	override void method(int x) {
		writeln("virtual C");
	}
}

void main(string[] args)
{
	A a = new A;
	a.method(7); //print virtual A
	a = new B;
	a.method(7);print virtual B
	a = new C;
	a.method(7); print virtual C
	stdin.readln;
}

"Andrei Alexandrescu"  wrote in message news:lndq8q$obh$1@digitalmars.com...

> > You did say that something with the same effect as 'virtual' was going in.
>
> No.

I am certain either you or Walter did in the last 'final by default' discussion.

> Please no new keyword for what can be done already. It's not proportional response.

Are you serious?  There absolutely is a need and we've been over this a thousand times. 

On Thursday, 12 June 2014 at 22:25:23 UTC, Kapps wrote:
> On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu
> wrote:
>> On 6/12/14, 6:34 AM, Dicebot wrote:
>>> On Wednesday, 11 June 2014 at 02:01:24 UTC, Brian Schott wrote:
>>>> Please do not tag anything until we decide if "virtual" is a keyword
>>>> in D.
>>>>
>>>> See: https://github.com/D-Programming-Language/dlang.org/pull/584
>>>
>>> It was decided and 100% certain - "virtual" is not going in. Need to
>>> remove it from DMD before this release is out.
>>
>> Yes please. -- Andrei
>
> That's pretty disappointing. Something similar to virtual is
> necessary, and that something should be actually clean, readable,
> and obvious. The proposed final(false), while it is generic, is
> long and ugly, a double negative (not not overridable), and not
> nicely readable / obvious. Best of all, it's simply another
> important thing that continues to never see any progress as it
> gets further ignored.
>
> The actual pull to add virtual had multiple pings, but the only
> response after being told that it was coming (along with
> final-by-default), was that it wouldn't be in 2.065 because that
> was a bug fix release. Three months later (after 2.065 came out)
> it actually got pulled, but this was only because someone else
> pulled it, at which point you expressed your disappointment at it
> being pulled. Then the issue again continued to be ignored for
> another 3.5 months after that while the keyword remained in git
> master the entire time. There's always talk of making things
> actually happen and that the community needing to step up to make
> them happen, yet people *have* stepped up to do all of this and
> been continually ignored. Even after being told final-by-default
> would not happen, it was (I believe?) said that a way of going
> virtual -> final would be added, allowing people to actually use
> 'final:'. But again, nothing came from that.
>
> We went from agreeing on final by default, to *possibly* getting
> an ugly way of going from final: -> virtual, provided that
> something is actually done about it instead of it being ignored
> further. It's been over a year since the original discussion of
> final by default, and agreement that *something* should be done,
> but in the past year absolutely nothing has happened related to
> it and no signs exist of anything happening in the next year
> either.

It's the same with rvalue references ('auto ref' for non templates). It gets ignored since 3 years or maybe longer and any community attempt to solve it was rejected - or also ignored. It's very funny to observe. :D
If it is "only" considered by the community as important, it gets usually ignored or (multiple) discussed to death.

On 6/13/14, 8:49 AM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lndq8q$obh$1@digitalmars.com...
>
>> > You did say that something with the same effect as 'virtual' was
>> going > in.
>>
>> No.
>
> I am certain either you or Walter did in the last 'final by default'
> discussion.

Walter got annoyed into approving this. It was a mistake. We can't add language features like that.

>> Please no new keyword for what can be done already. It's not
>> proportional response.
>
> Are you serious?  There absolutely is a need and we've been over this a
> thousand times.

Yes, and I have a good understanding of the points made, no need for a rehash. There is an implied assumption that the arguments are so good, anyone who actually understands them will agree with them. So if someon doesn't agree, it bears repeating them. I understand the arguments and don't agree with them.

Virtual by default will not change. Being able to negate the "final:" label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label.


Andrei

On Fri, 13 Jun 2014 12:49:32 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Virtual by default will not change. Being able to negate the "final:" label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label.

To that end, I thought we were moving towards a more scalable solution: like !final or final!false or final(false), which could be nice for metaprogramming.

-Steve

On 6/13/2014 12:49 PM, Andrei Alexandrescu wrote:
>
> Being able to negate the "final:"
> label is nice to have but not a must. Adding a keyword for that doesn't
> scale - it would mean we'd need to add one keyword to undo each label.
>

No it doesn't mean that. "virtual" is very well established industry-wide as the anti-final. Just because we accept that does not mean we can't still do @~pure, @nothrow(false) or whatever for the ones which don't already have well-established names.

On 6/13/14, 10:15 AM, Nick Sabalausky wrote:
> On 6/13/2014 12:49 PM, Andrei Alexandrescu wrote:
>>
>> Being able to negate the "final:"
>> label is nice to have but not a must. Adding a keyword for that doesn't
>> scale - it would mean we'd need to add one keyword to undo each label.
>>
>
> No it doesn't mean that. "virtual" is very well established
> industry-wide as the anti-final. Just because we accept that does not
> mean we can't still do @~pure, @nothrow(false) or whatever for the ones
> which don't already have well-established names.

I don't see it necessary to add the "virtual" as a keyword to D. -- Andrei

On Friday, 13 June 2014 at 17:12:44 UTC, Steven Schveighoffer
wrote:
> On Fri, 13 Jun 2014 12:49:32 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Virtual by default will not change. Being able to negate the "final:" label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label.
>
> To that end, I thought we were moving towards a more scalable solution: like !final or final!false or final(false), which could be nice for metaprogramming.
>
> -Steve

Yes that was the decision, and with the advantage that the
parameter can be computed at compile time.

On Friday, 13 June 2014 at 20:29:46 UTC, deadalnix wrote:
> On Friday, 13 June 2014 at 17:12:44 UTC, Steven Schveighoffer
> wrote:
>> On Fri, 13 Jun 2014 12:49:32 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Virtual by default will not change. Being able to negate the "final:" label is nice to have but not a must. Adding a keyword for that doesn't scale - it would mean we'd need to add one keyword to undo each label.
>>
>> To that end, I thought we were moving towards a more scalable solution: like !final or final!false or final(false), which could be nice for metaprogramming.
>>
>> -Steve
>
> Yes that was the decision, and with the advantage that the
> parameter can be computed at compile time.

I honestly don't see this as a noticeable advantage, at least in
the case of final. Not to mention you could just use "static
if(dovirtual) { result ~= "final(false)"; }".

Steven Schveighoffer:

> To that end, I thought we were moving towards a more scalable solution: like !final or final!false or final(false), which could be nice for metaprogramming.

This is a small problem:


void foo(in int x) {
    auto y = x;
    y++; // error
}


The current solution is long, requires a cast and is not fully DRY (the 'x' name is repeated twice):

import std.traits;
void foo(in int x) {
    Unqual!(typeof(x)) y = x;
    y++;
}


!const is useful here (I assume !const to be the same as !immutable):

void foo(in int x) {
    !const y = x;
    y++;
}

Bye,
bearophile