On Friday, 13 June 2014 at 00:31:32 UTC, Walter Bright wrote:
https://github.com/D-Programming-Language/dmd/pull/3655
Glad to hear it. Boost is such a simple license.
On Thursday, 12 June 2014 at 20:35:39 UTC, Rounin wrote:
Hey there!
Yeah, to expect people to register on LiveJournal in this age
of Facebook... Sorry about that; It must have been to deter the
spammers.
I don't leave comments if it is run through facebook, maybe one
day.
There should be
On 13/06/14 00:47, Dmitry Olshansky wrote:
Seems ironic to say that D has no legacy baggage compared to C++ and
then have a readily served self-defeat with the goofy 10. and .1 being
supported for the sake of compatibility with C :)
Is that still supported? I thought it was removed to be able
On 12/06/14 19:40, Nick Sabalausky wrote:
Personally, I wouldn't be comfortable trusting such a tool. Besides, I
find that upgrading a codebase to a newer language version is one of the
most trivial tasks I ever face in software development - even in D.
It's a cute trick, but not a worthwhile
On 13/06/14 02:31, Walter Bright wrote:
https://github.com/D-Programming-Language/dmd/pull/3655
Awesome. Thanks for opening up to a less restrictive license.
--
/Jacob Carlborg
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu
wrote:
On 6/12/14, 10:40 AM, Nick Sabalausky wrote:
On 6/10/2014 12:35 PM, justme wrote:
On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei
Alexandrescu wrote:
Of possible interest.
Another hint:
You should return an `int[2]` from `abc()` instead of `int[]`.
It's faster and doesn't require a heap allocation.
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+Licenseref=cmdform
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
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
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
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
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
On Fri, 13 Jun 2014 12:49:32 -0400, Andrei Alexandrescu
seewebsiteforem...@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
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
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
On Friday, 13 June 2014 at 17:12:44 UTC, Steven Schveighoffer
wrote:
On Fri, 13 Jun 2014 12:49:32 -0400, Andrei Alexandrescu
seewebsiteforem...@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
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
seewebsiteforem...@erdani.org wrote:
Virtual by default will not change. Being able to negate the
final:
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
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
seewebsiteforem...@erdani.org wrote:
Virtual by default
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
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
22 matches
Mail list logo
