www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 2.066 Alpha

reply Andrew Edwards <ridimz yahoo.com> writes:
It is time to begin preparations for the next release of DMD. I am aim 
for a two week beta release to commence on 30 June with branching of 
2.066 and end on 7 July with the release of 2.066.0.

Concurrently with this release, I would like to produce a maintenance 
release for 2.065. Please identify "non breaking" changes, ICEs, and 
regressions that are suitable of including in the 2.065.1.

Regards,
Andrew
Jun 10 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
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
Jun 10 2014
next sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 6/10/14, 10:01 PM, 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


The branch will not be created until 30 June. I trust that this will be 
sorted out by then.
Jun 10 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 11 June 2014 at 04:17:04 UTC, Andrew Edwards wrote:

 On 6/10/14, 10:01 PM, 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


 The branch will not be created until 30 June. I trust that this 
 will be sorted out by then.


I'll be there to test and bug report ! Thank for being the 
release lieutenant.
Jun 10 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 6/11/14, 2:23 AM, deadalnix wrote:

 I'll be there to test and bug report ! Thank for being the release
 lieutenant.


In my world a lieutenant is absolutely useless. Given the tutelage and 
guidance of solid staff non-commissioned officer, some day they will 
become productive members of the community. If they don't find such a 
mentor however, they will become loose cannons: destroying all in their 
path.

I tend to see life from a different perspective. Officers, in general, 
are quite useless. They are the "good idea fairies" who give little, if 
any, consideration to the ramifications of their ideas/proposals and 
will stop at nothing to see them come to fruition: regardless of 
consequences. Worse still, they are absolutely incapable of implementing 
the ideas/proposals they generate.

I prefer a "Chief and Indian" analogy. The Chief knows what needs to get 
done and, though she may not know have the tasks required to get the job 
done, leverages the strengths of the Indians to do so. The Indians 
provide the skills and know-how, and actually does the work.

This community needs far more Chiefs and Indians (arguably more Indians 
than Chiefs): and way less lieutenants.

Oh, wow! That was a pretty long way around to say thank you for your 
continued support.
Jun 11 2014
next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 6/11/14, 2:23 AM, deadalnix wrote:

 I'll be there to test and bug report ! Thank for being the release
 lieutenant.



 In my world a lieutenant is absolutely useless. Given the tutelage and
 guidance of solid staff non-commissioned officer, some day they will become
 productive members of the community. If they don't find such a mentor
 however, they will become loose cannons: destroying all in their path.

 I tend to see life from a different perspective. Officers, in general, are
 quite useless. They are the "good idea fairies" who give little, if any,
 consideration to the ramifications of their ideas/proposals and will stop at
 nothing to see them come to fruition: regardless of consequences. Worse
 still, they are absolutely incapable of implementing the ideas/proposals
 they generate.

 I prefer a "Chief and Indian" analogy. The Chief knows what needs to get
 done and, though she may not know have the tasks required to get the job
 done, leverages the strengths of the Indians to do so. The Indians provide
 the skills and know-how, and actually does the work.

 This community needs far more Chiefs and Indians (arguably more Indians than
 Chiefs): and way less lieutenants.

 Oh, wow! That was a pretty long way around to say thank you for your
 continued support.



Nice analogy (and outlook!)

Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say
that the release timings are abysmal.  At least 2 months overdue.  I
have only just managed to catch up to 2.065, and that's not due out
till the weekend.

Things used to be so much easier when releases were less than 2 months apart.
Jun 11 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 6/11/14, 11:24 AM, Iain Buclaw via Digitalmars-d-announce wrote:

 On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 6/11/14, 2:23 AM, deadalnix wrote:

 I'll be there to test and bug report ! Thank for being the release
 lieutenant.



 In my world a lieutenant is absolutely useless. Given the tutelage and
 guidance of solid staff non-commissioned officer, some day they will become
 productive members of the community. If they don't find such a mentor
 however, they will become loose cannons: destroying all in their path.

 I tend to see life from a different perspective. Officers, in general, are
 quite useless. They are the "good idea fairies" who give little, if any,
 consideration to the ramifications of their ideas/proposals and will stop at
 nothing to see them come to fruition: regardless of consequences. Worse
 still, they are absolutely incapable of implementing the ideas/proposals
 they generate.

 I prefer a "Chief and Indian" analogy. The Chief knows what needs to get
 done and, though she may not know have the tasks required to get the job
 done, leverages the strengths of the Indians to do so. The Indians provide
 the skills and know-how, and actually does the work.

 This community needs far more Chiefs and Indians (arguably more Indians than
 Chiefs): and way less lieutenants.

 Oh, wow! That was a pretty long way around to say thank you for your
 continued support.



 Nice analogy (and outlook!)

 Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say
 that the release timings are abysmal.  At least 2 months overdue.  I
 have only just managed to catch up to 2.065, and that's not due out
 till the weekend.

 Things used to be so much easier when releases were less than 2 months apart.


You are absolutely correct... I was asked to delay the April and, after 
that, my personal life took precedence. I am aiming is to get back on 
track with a two month release cycle. The maintenance releases will 
remain on a six month cycle though.
Jun 11 2014
parent Iain Buclaw via Digitalmars-d-announce writes:
On 11 June 2014 17:56, Andrew Edwards via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On 6/11/14, 11:24 AM, Iain Buclaw via Digitalmars-d-announce wrote:

 On 11 June 2014 14:19, Andrew Edwards via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 On 6/11/14, 2:23 AM, deadalnix wrote:

 I'll be there to test and bug report ! Thank for being the release
 lieutenant.




 In my world a lieutenant is absolutely useless. Given the tutelage and
 guidance of solid staff non-commissioned officer, some day they will
 become
 productive members of the community. If they don't find such a mentor
 however, they will become loose cannons: destroying all in their path.

 I tend to see life from a different perspective. Officers, in general,
 are
 quite useless. They are the "good idea fairies" who give little, if any,
 consideration to the ramifications of their ideas/proposals and will stop
 at
 nothing to see them come to fruition: regardless of consequences. Worse
 still, they are absolutely incapable of implementing the ideas/proposals
 they generate.

 I prefer a "Chief and Indian" analogy. The Chief knows what needs to get
 done and, though she may not know have the tasks required to get the job
 done, leverages the strengths of the Indians to do so. The Indians
 provide
 the skills and know-how, and actually does the work.

 This community needs far more Chiefs and Indians (arguably more Indians
 than
 Chiefs): and way less lieutenants.

 Oh, wow! That was a pretty long way around to say thank you for your
 continued support.




 Nice analogy (and outlook!)

 Now, as 'Chief' of GDC talking to 'Chief' or D releases, I must say
 that the release timings are abysmal.  At least 2 months overdue.  I
 have only just managed to catch up to 2.065, and that's not due out
 till the weekend.

 Things used to be so much easier when releases were less than 2 months
 apart.


 You are absolutely correct... I was asked to delay the April and, after
 that, my personal life took precedence. I am aiming is to get back on track
 with a two month release cycle. The maintenance releases will remain on a
 six month cycle though.



FYI, I have actually collected some stats about DMD vs GDC supported
D2 versions and their dates.  It's quite interesting, and ends with a
guestimation of the 2.067 release date, followed by how long till
2.066 will be merge down into GDC. :-)

Maybe this should be posted somewhere, Andrei?

http://gdcproject.org/data/gdc-dmd-v2release.svg
Jun 11 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/11/2014 9:19 AM, Andrew Edwards wrote:

 On 6/11/14, 2:23 AM, deadalnix wrote:

 I'll be there to test and bug report ! Thank for being the release
 lieutenant.


 In my world a lieutenant is absolutely useless. Given the tutelage and
 guidance of solid staff non-commissioned officer, some day they will
 become productive members of the community. If they don't find such a
 mentor however, they will become loose cannons: destroying all in their
 path.

 I tend to see life from a different perspective. Officers, in general,
 are quite useless. They are the "good idea fairies" who give little, if
 any, consideration to the ramifications of their ideas/proposals and
 will stop at nothing to see them come to fruition: regardless of
 consequences. Worse still, they are absolutely incapable of implementing
 the ideas/proposals they generate.


Reminds me of both MBAs and MASH ;)
Jun 11 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jun 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 12 2014
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Jun 12 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/14, 3:25 PM, 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.


I don't think it's that important. And definitely there's no ignoring 
going on. There are plenty of things that are plenty more important, and 
final/virtual functions can already be done easily.

Andrei
Jun 12 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote:

 and
 final/virtual functions can already be done easily.


But "final:" can't.
Jun 12 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote:

 I don't think it's that important. And definitely there's no ignoring
 going on. There are plenty of things that are plenty more important,


Wait, so now we're rejecting work that isn't at the right priority 
level? Some people did seem to find "final:" (and therefore "virtual") 
important to them, so this really seems to fly in the face of the DConf 
talk about D development involving people "scratching their own itches".
Jun 12 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/14, 5:50 PM, Nick Sabalausky wrote:

 On 6/12/2014 8:06 PM, Andrei Alexandrescu wrote:

 I don't think it's that important. And definitely there's no ignoring
 going on. There are plenty of things that are plenty more important,


 Wait, so now we're rejecting work that isn't at the right priority
 level?


No. I am rejecting work I do not agree with.


 Some people did seem to find "final:" (and therefore "virtual")
 important to them, so this really seems to fly in the face of the DConf
 talk about D development involving people "scratching their own itches".


I am sorry, this angle is completely mistaken.


Andrei
Jun 12 2014
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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.
Jun 13 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:lncrb0$31ec$1 digitalmars.com...


 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


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

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)
Jun 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/14, 7:26 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:lncrb0$31ec$1 digitalmars.com...


 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


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


No.


 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.


Andrei
Jun 12 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 12 2014
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
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;
}
Jun 13 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Jun 13 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 13 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jun 13 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jun 13 2014
parent reply "Kapps" <opantm2+spam gmail.com> writes:
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)"; }".
Jun 13 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 13 June 2014 at 20:52:17 UTC, Kapps wrote:

 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)"; }".


That is a plus for generic code, and that work for virtual.

So there is reason to use something specific for virtual.
Consistency is a plus in its own right. Coming up with ad hoc
solution to every problem is an absolutely terrible way to design
a programming language.
Jun 13 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jun 13 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Jun 13 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 13 2014
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Fri, 13 Jun 2014 12:00:39 -0700
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:


 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. --


If we were going to go with final by default, then adding virtual would make a
lot of sense IMHO - especially given that's what people expect from other
languages and the fact that virtual would the likely be used far more often
than final. Without that however, marking a function as virtual becomes a lot
less critical, and it becomes a question of whether the familiarity of using
virtual instead of !final or final(false) (or whatever we come up with) is
worth adding another keyword and having it in addition to !final or
final(false) or whatever (since presumably, we'd still need that for generic
code even with virtual). And actually, having virtual would then open the door
for !virtual or virtual(false) or whatever in addition to !final or
final(false), etc. So, while having virtual would be nice, it's probably
complicating things too much from the user's perspective when combined with
the ability to explicitly negate attributes.

- Jonathan M Davis
Jun 14 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/14/2014 5:49 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

 and it becomes a question of whether the familiarity of using
 virtual instead of !final or final(false) (or whatever we come up with) is
 worth adding another keyword


FWIW, I don't think "virtual" is all that valuable as a user-defined 
keyword anyway. But, emphasis on "FWIW".
Jun 14 2014
prev sibling parent reply "Tove" <Tove fransson.se> writes:
On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu 
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.


 Andrei


Just to try and establish a clear path forwards,
if a pull request existed which added support for...
final!true
final!false
... would it be accepted?

Or would a generic negate-x-DIP be required?
const!false
noexcept!false
etc.
Jun 15 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/14, 12:30 AM, Tove wrote:

 On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu 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.


 Andrei


 Just to try and establish a clear path forwards,
 if a pull request existed which added support for...
 final!true
 final!false
 .... would it be accepted?

 Or would a generic negate-x-DIP be required?
 const!false
 noexcept!false
 etc.


I think we'd need an approved DIP. -- Andrei
Jun 15 2014
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu 
wrote:

 On 6/12/14, 6:34 AM, Dicebot wrote:

 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


Since we didn't seem to have a pull request for removing the 
attribute: https://github.com/D-Programming-Language/dmd/pull/3663

David
Jun 14 2014