On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu
wrote:
D1's approach to multithreading was wanting. D2 executed a big
departure from that with the shared qualifier and the
default-thread-local approach to data.
We think this is a win, but D2 inherited a lot of D1's
thread-relate
On Wednesday, 19 March 2014 at 10:41:59 UTC, bearophile wrote:
Kagamin:
Don't even think, ranges are not better.
I am thinking about syntax sugar that the compiler uses to
create a input/forward range similar to this:
http://forum.dlang.org/post/awabysprjjnrxrhgq...@forum.dlang.org
There
Kagamin:
Don't even think, ranges are not better.
I am thinking about syntax sugar that the compiler uses to create
a input/forward range similar to this:
http://forum.dlang.org/post/awabysprjjnrxrhgq...@forum.dlang.org
Bye,
bearophile
On Sunday, 16 March 2014 at 13:55:24 UTC, bearophile wrote:
Benjamin Thaut:
Could you please explain in a bit more detail why you think
opApply should be deprecated?
To replace it with something better.
Don't even think, ranges are not better.
On Tuesday, 18 March 2014 at 13:49:54 UTC, Dicebot wrote:
I still have zero understanding of what "synchronized" is
supposed to mean an only vague guesses about "shared". Probably
have never used either of those apart of "shared static this()"
module constructors. Having some examples of how co
On 3/18/14, 6:49 AM, Dicebot wrote:
I still have zero understanding of what "synchronized" is supposed to
mean an only vague guesses about "shared". Probably have never used
either of those apart of "shared static this()" module constructors.
Having some examples of how code is supposed to behave
On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu
wrote:
D1's approach to multithreading was wanting. D2 executed a big
departure from that with the shared qualifier and the
default-thread-local approach to data.
We think this is a win, but D2 inherited a lot of D1's
thread-relate
Am Mon, 17 Mar 2014 14:16:19 +
schrieb "Jesse Phillips" :
> On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
> >> Deprecation is breaking code, it's a good way to to do it, but
> >> you shouldn't kid yourself that it isn't a breaking change.
> >
> > It certainly is a subjective ma
On Monday, 17 March 2014 at 08:48:36 UTC, Andrea wrote:
IMHO we have a bunch of breaking changes already planned for
the future and it'll be a bit more difficult than that to fix
the code. Maybe I'm not aware of it and it already exists, but
we should create a page where deprecated features are
On Monday, 17 March 2014 at 08:48:36 UTC, Andrea wrote:
IMHO we have a bunch of breaking changes already planned for
the future and it'll be a bit more difficult than that to fix
the code. Maybe I'm not aware of it and it already exists, but
we should create a page where deprecated features are
On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
Deprecation is breaking code, it's a good way to to do it, but
you shouldn't kid yourself that it isn't a breaking change.
It certainly is a subjective matter.
I don't see how it is. How do you define a change which has
broken code
On Monday, 17 March 2014 at 05:14:40 UTC, Marco Leise wrote:
Am Mon, 17 Mar 2014 03:57:10 +
schrieb "Jesse Phillips" :
On Sunday, 16 March 2014 at 21:15:29 UTC, Martin Nowak wrote:
> Please think hard about this. Why does it need to break code?
> Can't we have a proper deprecation cycle?
>
On Sunday, 16 March 2014 at 15:05:45 UTC, Andrej Mitrovic wrote:
On 3/16/14, Andrea wrote:
In the
short term the current "broken" code will still work without
having to be rewritten.
You'll end up in the same situation as Python 3. Most people
will not
only keep existing code, but continue t
Am Mon, 17 Mar 2014 03:57:10 +
schrieb "Jesse Phillips" :
> On Sunday, 16 March 2014 at 21:15:29 UTC, Martin Nowak wrote:
> > Please think hard about this. Why does it need to break code?
> > Can't we have a proper deprecation cycle?
> > Until now it was always possible to add proper deprecati
On Sunday, 16 March 2014 at 21:15:29 UTC, Martin Nowak wrote:
Please think hard about this. Why does it need to break code?
Can't we have a proper deprecation cycle?
Until now it was always possible to add proper deprecation
warnings and allow people to transition code at their own pace.
I'm op
On 03/16/2014 05:08 AM, Andrei Alexandrescu wrote:
This will statically break code. It will refuse to compile code that is
incorrect, but also plenty of code that is correct; the compiler will
demand extra guarantees from user code, be they in the form of casts and
stated assumptions.
I believe
On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu
wrote:
I believe this is a bridge we do need to cross. One question is
how we go about it: all at once, or gradually?
I don't think this is quite the right question to ask. In the
ideal, all changes would be placed in the compiler a
Andrei Alexandrescu:
On 3/16/14, 8:59 AM, bearophile wrote:
(and some Rust people say D "scope" can't be very
useful).
[citation needed]
It was part of a much longer discussion on Reddit, few weeks ago.
"scope" is a blunt tool compared to the region analysis of Rust.
But this is not impor
On 3/16/14, 8:59 AM, bearophile wrote:
(and some Rust people say D "scope" can't be very
useful).
[citation needed]
Andrei
Another breaking change could be the
I think the implementation of "scope" could break quite more user
code than the introduction of "final by default" class methods,
because "in" function argument are common and they mean "scope
const". There is not even a DIP for scope (and some Rust people
On Sun, 2014-03-16 at 16:05 +0100, Andrej Mitrovic wrote:
[…]
> You'll end up in the same situation as Python 3. Most people will not
> only keep existing code, but continue to write *more of it*. By the
> time the "compatibility profile" is removed, it's going to become 100x
> harder to change all
On 3/16/14, Andrea wrote:
> In the
> short term the current "broken" code will still work without
> having to be rewritten.
You'll end up in the same situation as Python 3. Most people will not
only keep existing code, but continue to write *more of it*. By the
time the "compatibility profile" is
I'm a newcomer to D so I may not be aware of many things that are
going on in this community. If by any change I write anything
stupid let me know. Also this may not be the right thread to post
this and I'm sorry for that. That being said...
I'm seeing a lot a major breaking changes being disc
Benjamin Thaut:
Could you please explain in a bit more detail why you think
opApply should be deprecated?
To replace it with something better. But this discussion is
off-topic for this thread, that is about "synchronized" or its
alternatives. I didn't mean to derail the main thread.
Bye,
b
Am 16.03.2014 13:44, schrieb bearophile:
Another breaking change could be the deprecation of the now nearly
useless opApply() (only std.array.array works with it) and replacing it
with a nice external iterator D syntax sugar to define a forward iterator:
http://journal.stuffwithstuff.com/2013/01
On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu
wrote:
I believe this is a bridge we do need to cross. One question is
how we go about it: all at once, or gradually?
IMHO, it would be better to do all-at-once.
It would also be better to target a release to work on this issue
(eg.
Another breaking change could be the deprecation of the now
nearly useless opApply() (only std.array.array works with it) and
replacing it with a nice external iterator D syntax sugar to
define a forward iterator:
http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/
Another
On 16.3.2014. 5:08, Andrei Alexandrescu wrote:
> D1's approach to multithreading was wanting. D2 executed a big departure
> from that with the shared qualifier and the default-thread-local
> approach to data.
>
> We think this is a win, but D2 inherited a lot of D1's thread-related
> behavior by d
On 2014-03-16 04:08:18 +, Andrei Alexandrescu
said:
Fixing that has not gained focus until recently, when e.g.
https://github.com/D-Programming-Language/dmd/pull/3067 has come about.
Synchronized classes should be trashed.
The whole concept is very prone to mistakes that could cause dea
On Sat, 2014-03-15 at 21:08 -0700, Andrei Alexandrescu wrote:
[…]
> I believe this is a bridge we do need to cross. One question is how we
> go about it: all at once, or gradually?
Given that it is a breaking change, the sooner the better and as much of
it at once as possible. Perhaps changing th
On Sunday, 16 March 2014 at 04:08:15 UTC, Andrei Alexandrescu
wrote:
D1's approach to multithreading was wanting. D2 executed a big
departure from that with the shared qualifier and the
default-thread-local approach to data.
We think this is a win, but D2 inherited a lot of D1's
thread-relate
ASAP please.
Dne 16. 3. 2014 5:10 "Andrei Alexandrescu"
napsal(a):
> D1's approach to multithreading was wanting. D2 executed a big departure
> from that with the shared qualifier and the default-thread-local approach
> to data.
>
> We think this is a win, but D2 inherited a lot of D1's thread-re
D1's approach to multithreading was wanting. D2 executed a big departure
from that with the shared qualifier and the default-thread-local
approach to data.
We think this is a win, but D2 inherited a lot of D1's thread-related
behavior by default, and some of the rules introduced by TDPL
(http
33 matches
Mail list logo
