Re: Pushing D's mixin to the limits: Project Euler Problem 61 from Ruby to D by David Oftedal
Another hint: You should return an `int[2]` from `abc()` instead of `int[]`. It's faster and doesn't require a heap allocation.
Re: dmd front end now switched to Boost license
On 6/12/14, 8:31 PM, Walter Bright wrote: https://github.com/D-Programming-Language/dmd/pull/3655 Seems you missed a few: https://github.com/D-Programming-Language/dmd/search?q=Artistic+License&ref=cmdform
Re: dmd front end now switched to Boost license
13-Jun-2014 04:31, Walter Bright пишет: https://github.com/D-Programming-Language/dmd/pull/3655 It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. -- Dmitry Olshansky
Re: DMD 2.066 Alpha
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;
}
Re: DMD 2.066 Alpha
"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.
Re: DMD 2.066 Alpha
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.
Re: DMD 2.066 Alpha
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
Re: DMD 2.066 Alpha
On Fri, 13 Jun 2014 12:49:32 -0400, 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. 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
Re: DMD 2.066 Alpha
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.
Re: DMD 2.066 Alpha
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
Re: DMD 2.066 Alpha
On Friday, 13 June 2014 at 17:12:44 UTC, Steven Schveighoffer wrote: On Fri, 13 Jun 2014 12:49:32 -0400, 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. 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.
Re: DMD 2.066 Alpha
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
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)"; }".
Re: DMD 2.066 Alpha
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
Re: DMD 2.066 Alpha
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
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.
Re: dmd front end now switched to Boost license
On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote: 13-Jun-2014 04:31, Walter Bright пишет: https://github.com/D-Programming-Language/dmd/pull/3655 It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ?
Re: dmd front end now switched to Boost license
On 6/13/2014 4:31 AM, Dmitry Olshansky wrote: It's probably nice to have less restrictive license, but what we aim to achieve with that? 1. Boost is the least restrictive license 2. Minimize friction for adopting D 3. Harmonization with usage of Boost in the runtime library 4. Allow commercial use of DMDFE (so what if someone does? It'll drive even more adoption of D!) 5. Boost is well known and accepted
Re: dmd front end now switched to Boost license
On 6/13/2014 8:15 PM, Mathias LANG wrote: On Friday, 13 June 2014 at 11:31:10 UTC, Dmitry Olshansky wrote: 13-Jun-2014 04:31, Walter Bright пишет: https://github.com/D-Programming-Language/dmd/pull/3655 Heh, I had been under the impression was already Boost. :P It's probably nice to have less restrictive license, but what we aim to achieve with that? Make commercial companies contribute to DMD more freely? There is no problem even with GPL. Let them build and sell their own products out of DMDFE? Highly unlikely to be a profitable anyway, and we'd better get back the patches. Wild guess: DMD in fedora, debian et al. repositories ? I doubt it. First, it's the backend that's not technically OSI, frontend was (apparently) GPL. Second, I can't imagine any Linux distro rejecting GPL - they'd have to boot the kernel and core utils, too. Boost has kinda become the favored "D" license anyway, Phobos etc., so it probably has a lot to do with that. Kinda weird to have the compiler and stdlib under different licenses.
