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