On Wednesday, 16 October 2019 at 15:23:01 UTC, Paolo Invernizzi
wrote:
On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves
wrote:
[...]
I don't think it's political: the change implies breakage for
downstream users who inherit from the class who might not even
care about @nogc.
Th
On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote:
Please take a look at the cited pull request: it's a *trivial*
Phobos patch, that can be added aside to the current
implementation, blocked for months waiting for a _political_
decision.
I don't think it's political: the chang
On Wednesday, 16 October 2019 at 12:32:28 UTC, Paolo Invernizzi
wrote:
On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves
wrote:
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright
wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @
On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves wrote:
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright
wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe)
deprecating the previous method is seen as 'annoying'
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe)
deprecating the previous method is seen as 'annoying', also if
it's a _clear_ improvement over the actual situation (yo
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote:
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe)
deprecating the previous method is seen as 'annoying', also if
it's a _clear_ improvement over the actual situation (yo
On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
- adding another method to a class, marked @nogc, and (maybe) deprecating the
previous method is seen as 'annoying', also if it's a _clear_ improvement over
the actual situation (you can write _better_ code with that in place compared to
the actual
On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote:
On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
Well, so there's hope that _very little_ improvements will be
merged, in a way or another? I mean, there's some sort of
policy for things like that:
https://github.com/dlang/phobo
On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
Phobos is amazing and stable, but exactly because of these
attributes there isn't much active development happening.
I thought that the work on dip1000 and the current push for
borrow semantics and other lifetime related issues that have
c
On Monday, 7 October 2019 at 08:07:01 UTC, Joseph Rushton
Wakeling wrote:
Where's the breaking change? Are there selections of handlers
that work for visit and don't work with match?
Yes.
https://run.dlang.io/is/UpaY2E
On Monday, 7 October 2019 at 01:38:04 UTC, Paul Backus wrote:
Just to clarify: SumType isn't, and was never intended to be, a
drop-in replacement for Algebraic. Their interfaces are similar
enough that porting code from Algebraic to SumType shouldn't be
too difficult, but even within the common
On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote:
On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
Well, so there's hope that _very little_ improvements will be
merged, in a way or another? I mean, there's some sort of
policy for things like that:
https://github.com/dlang/phobo
On Monday, 7 October 2019 at 01:09:34 UTC, Andrei Alexandrescu
wrote:
Well also in the case of SumType there's not even much
battle-testing. It's more of an implementation than a design.
Take the existing variant, keep the interface, remove the
cruft, put in the new nice code. Make it pass the
On 10/6/19 3:09 AM, Joseph Rushton Wakeling wrote:
You misunderstand what I mean by "battle-testing". Clearly designs
should go through a high level of testing and usage before they go
anywhere near the standard library. But the very fact of being placed in
the standard library exposes them to
On Sunday, 6 October 2019 at 21:49:59 UTC, Joseph Rushton
Wakeling wrote:
I'm not fluent in assembly so, leaving the error path aside, I
wasn't sure how to interpret the "main path" assembly from the
D and Rust code, and whether they were practically equivalent
(clearly the assembly posted look
On Sunday, 6 October 2019 at 14:08:07 UTC, Adam D. Ruppe wrote:
D can eliminate error paths at compile time too, e.g. static
assert - which can be used to create all kinds of new useful
errors. So I am guessing this is just a case of the code
needing a lil tweak or the compiler being conservati
On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
Well, so there's hope that _very little_ improvements will be merged, in a way
or another? I mean, there's some sort of policy for things like that:
https://github.com/dlang/phobos/pull/6730
Frankly speaking, the actual situation it's a little
On Sunday, 6 October 2019 at 08:31:20 UTC, Dennis wrote:
On Sunday, 6 October 2019 at 00:58:17 UTC, SrMordred wrote:
But why if this is a final switch? (also assert(0); at the end
don´t help )
Because the optimization hasn't been implemented yet.
https://issues.dlang.org/show_bug.cgi?id=13169
On Sunday, 6 October 2019 at 07:18:37 UTC, Joseph Rushton
Wakeling wrote:
Speaking of performance, I was intrigued by the Reddit response
noting that Rust can go one better by eliminating the error
path at compile time:
D can eliminate error paths at compile time too, e.g. static
assert - whi
On Sunday, 6 October 2019 at 02:33:15 UTC, Walter Bright wrote:
On 10/5/2019 6:58 AM, Seb wrote:
Phobos is essentially dead/frozen (feature-wise).
I beg to disagree. A couple cases in point:
https://github.com/dlang/phobos/pull/7211
which is a re-imagining, rethinking of hexString.
and:
On Sunday, 6 October 2019 at 08:27:35 UTC, Seb wrote:
Well, my guess it will be similar [...]
If you're not the one making those decisions it may be better not
to prejudge them. A significant performance improvement is a
different beast to moderate API/usability improvements.
A standard lib
On Sunday, 6 October 2019 at 00:58:17 UTC, SrMordred wrote:
But why if this is a final switch? (also assert(0); at the end
don´t help )
Because the optimization hasn't been implemented yet.
https://issues.dlang.org/show_bug.cgi?id=13169
On Sunday, 6 October 2019 at 07:16:03 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
My earlier post tried to point out that SumType is an
excellent candidate for v2.
Sorry, Seb, but I don't get this. There's no reason to wait for
a v2 to introduce a
On Sunday, 6 October 2019 at 00:52:38 UTC, Andrei Alexandrescu
wrote:
Anyhow, currently we would have to name it differently (e.g.
dts - https://github.com/wilzbach/dts). Maybe the upcoming
SAoC project will change this and allow multiple versions of a
library to co-exist in a binary.
Adding
Speaking of performance, I was intrigued by the Reddit response
noting that Rust can go one better by eliminating the error path
at compile time:
https://www.reddit.com/r/programming/comments/ddi5wb/comment/f2iow4u
The commenter suggests that's because Rust bakes the
functionality into the com
On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
My earlier post tried to point out that SumType is an excellent
candidate for v2.
Sorry, Seb, but I don't get this. There's no reason to wait for a
v2 to introduce a new SumType symbol that outperforms the old
Variant (assuming it's not po
On Sunday, 6 October 2019 at 02:33:15 UTC, Walter Bright wrote:
On 10/5/2019 6:58 AM, Seb wrote:
Phobos is essentially dead/frozen (feature-wise).
I beg to disagree. A couple cases in point:
https://github.com/dlang/phobos/pull/7211
which is a re-imagining, rethinking of hexString.
I'm
On 10/5/2019 6:58 AM, Seb wrote:
Phobos is essentially dead/frozen (feature-wise).
I beg to disagree. A couple cases in point:
https://github.com/dlang/phobos/pull/7211
which is a re-imagining, rethinking of hexString.
and:
https://github.com/dlang/phobos/pull/7130
https://github
I wonder about the generated Assembly:
In Rust if u add #[repr(usize)] to the enum the generated code as
only two lines.
In D, Look like the first assembly lines are checking for
errors(or out of bounds index?).
But why if this is a final switch? (also assert(0); at the end
don´t help )
On 10/5/19 7:58 AM, Seb wrote:
On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran wrote:
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options we
have in D, like Algebraic and SumType, so I did a simple compa
On Saturday, 5 October 2019 at 13:58:52 UTC, Seb wrote:
On Saturday, 5 October 2019 at 06:40:35 UTC, Arun
Chandrasekaran wrote:
Good one. Any plans to push SumType as a replacement of
Phobo's Algebraic?
Phobos is essentially dead/frozen (feature-wise). Though if
someone ever manages to get v2
On Saturday, 5 October 2019 at 04:07:45 UTC, Meta wrote:
I'm not sure if you're aware, but funnily enough, I also wrote
an article[1] on std::variant vs. the D alternative that
references Matt Kline's article on std::visit. It seems we're
really making getting our money's worth from his article
On Saturday, 5 October 2019 at 12:27:06 UTC, Mike Parker wrote:
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for eac
On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran
wrote:
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you c
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you c
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you c
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you c
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
I was curious how C++17's std::variant compared to the options
we have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you c
I was curious how C++17's std::variant compared to the options we
have in D, like Algebraic and SumType, so I did a simple
comparison of the generated assembly for each of them. You can
read about it at the link below. And as you can probably guess
from the title, D comes out ahead, in the end.
40 matches
Mail list logo
