On Thursday, 18 June 2015 at 16:44:04 UTC, Andrei Alexandrescu
wrote:
Thanks for the input. So I'll go with the option of adding
std.experimental.collection and leave std.container be at least
for now.
There'll be std.experimental.collection.mutable and
std.experimental.collection.functional
Thanks for the input. So I'll go with the option of adding
std.experimental.collection and leave std.container be at least for now.
There'll be std.experimental.collection.mutable and
std.experimental.collection.functional because they have complementary
strengths. Any pointers to functional
On 06/18/2015 06:44 PM, Andrei Alexandrescu wrote:
Thanks for the input. So I'll go with the option of adding
std.experimental.collection and leave std.container be at least for now.
There'll be std.experimental.collection.mutable and
std.experimental.collection.functional because they have
On Tue, 16 Jun 2015 23:08:56 -0700, Andrei Alexandrescu wrote:
...
I strongly favor going with 3.
There is no need to be tied up to the old design in anyway and there is
no need to break people's code. If the name is such an issue for some
people, I suggest `std.container.v2`.
On Wednesday, 17 June 2015 at 16:21:18 UTC, ixid wrote:
On Wednesday, 17 June 2015 at 15:57:38 UTC, Wyatt wrote:
But sanity and API versioning may exist at opposite ends
of a spectrum, if I recall my history.
What are the downsides?
Issues, off the top of my head: figuring out which is
On Wednesday, 17 June 2015 at 16:00:30 UTC, Wyatt wrote:
I guess I'll have to wait for Adam's write-up, then.
I'm probably going to write that one tomorrow, but won't post it
until Sunday night/Monday morning.
The short of it is to check for what methods are available
instead of trying to
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
This is another manifestation of the systemic problem of our
community that's been discussed here in the past - there are
matters that greatly affect negatively the uptake of D, yet
they stay unresolved for literally months
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better alongside them.
2. Do break compatibility of containers, mainly by taking
advantage of them being under-documented. In a way
(3)
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective, and my assessment is as follows:
...
Andrei
2 or 3, I wouldn't mind breaking changes, personally I feel like
D has gotten too scared of
On 6/17/15 7:57 AM, Wyatt wrote:
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu wrote:
Took a fresh look at std.container from a Design by Introspection
perspective
I've seen you use this term a few times now; what does it mean? (Lack
of) Google results seem to indicate it's
On 6/17/15 8:17 AM, rsw0x wrote:
On Wednesday, 17 June 2015 at 15:03:40 UTC, Andrei Alexandrescu wrote:
On 6/17/15 2:59 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
I think this decision should be left to the end-user. A container that
supports only RC is just as bad as one that
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better
On Wednesday, 17 June 2015 at 10:58:58 UTC, weaselcat wrote:
(3)
After some more thought, I agree with this. std.container could
just be warned against using in favor of std.collections.
I agree, deprecation is a good balance between the agile
evolution of D contra user friendlieness.
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
3. Leave std.container alone and move forward with
std.experimental.collection. I am confident the language and
its endorsed idioms have reached enough maturity to not make
this addition into a regular event.
I'm really
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective, and my assessment is as follows:
[...]
3.
Implement std.experimental.collection and leave std.container for
backwards compatibility. Then
Took a fresh look at std.container from a Design by Introspection
perspective, and my assessment is as follows:
* The current design of std.container is adequate but requires rather
verbose implementations because it predates UFCS. For example,
containers that define stableRemove must also
On 6/17/2015 3:08 PM, Andrei Alexandrescu wrote:
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers are and
will remain garbage collected because they started as such. Add new
containers that are better alongside them.
2. Do
On 17/06/2015 6:08 p.m., Andrei Alexandrescu wrote:
Took a fresh look at std.container from a Design by Introspection
perspective, and my assessment is as follows:
* The current design of std.container is adequate but requires rather
verbose implementations because it predates UFCS. For
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Regarding compatibility, I see three possibilities:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better
On Wednesday, 17 June 2015 at 10:07:17 UTC, Walter Bright wrote:
(3)
3, it facilitates benchmarking both implementations in apps, even
when using the binary d distriburion.
(3)
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Consider e.g. SList!T.clear(). Right now it's O(1) and only
reassigns the root to point to no element, thus leaving all
elements to be collected. Moreover, if there are ranges
iterating the now cleared list, they'll just
On Wednesday, 17 June 2015 at 10:07:17 UTC, Walter Bright wrote:
(3)
After some more thought, I agree with this. std.container could
just be warned against using in favor of std.collections.
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
...
2. I've never used std.container, it looks incomplete.
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better alongside them.
2. Do break compatibility of
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Even if we implement the change to be memory-safe, there's
still changes in semantics (e.g. the behavior of orphan ranges
changes). And even if we change behavior that wasn't specified
explicitly in the docs, it's still a
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
3. Leave std.container alone and move forward with
std.experimental.collection. I am confident the language and
its endorsed idioms have reached enough maturity to not make
this addition into a regular event.
How about 3
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Regarding compatibility, I see three possibilities:
I believe that at this moment it is necessary to implement step
3, but...
In the future, it is necessary to refine and revise std.container.
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
1. Just keep the current spec and deal with it. Some containers
are and will remain garbage collected because they started as
such. Add new containers that are better alongside them.
2. Do break compatibility of
On 6/17/15 2:59 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
I think this decision should be left to the end-user. A container that
supports only RC is just as bad as one that supports only GC. Instead,
use SList!T or SList!(Unique!T) or SList(RefCounted!T) as appropriate.
All
On Wednesday, 17 June 2015 at 15:03:40 UTC, Andrei Alexandrescu
wrote:
On 6/17/15 2:59 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
I think this decision should be left to the end-user. A
container that
supports only RC is just as bad as one that supports only GC.
Instead,
use
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective, and my assessment is as follows:
[...]
(3)
On Wednesday, 17 June 2015 at 14:57:40 UTC, Wyatt wrote:
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective
I've seen you use this term a few times now; what does it mean?
(Lack of) Google
On Wed, 17 Jun 2015 14:57:38 +, Wyatt wrote:
'm not
using std.container anywhere and I suspect it's much the same for most
everyone else.
it seems that people rolling their own containers, preferring to stay
away from std.container. so i don't think that it is used anywhere
except some
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective
I've seen you use this term a few times now; what does it mean?
(Lack of) Google results seem to indicate it's your own neologism.
* The
On Wednesday, 17 June 2015 at 15:57:38 UTC, Wyatt wrote:
On Wednesday, 17 June 2015 at 15:29:34 UTC, ixid wrote:
On Wednesday, 17 June 2015 at 14:57:40 UTC, Wyatt wrote:
but std.collection isn't nearly so good a name.
std.container2 and so on?
Dunno. That's not something that really needs
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
2. Do break compatibility of containers, mainly by taking
advantage of them being under-documented. In a way we wouldn't
break much because not much has been specified. There are,
however, parts where we'd need to change
On Wednesday, 17 June 2015 at 14:57:40 UTC, Wyatt wrote:
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu
wrote:
Took a fresh look at std.container from a Design by
Introspection perspective
I've seen you use this term a few times now; what does it mean?
(Lack of) Google
On Wednesday, 17 June 2015 at 15:29:34 UTC, ixid wrote:
On Wednesday, 17 June 2015 at 14:57:40 UTC, Wyatt wrote:
but std.collection isn't nearly so good a name.
std.container2 and so on?
Dunno. That's not something that really needs addressed right
now, is it? Off-the-cuff, in an ideal
On Wednesday, 17 June 2015 at 15:50:51 UTC, John Colvin wrote:
On Wednesday, 17 June 2015 at 14:57:40 UTC, Wyatt wrote:
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei
Alexandrescu wrote:
Took a fresh look at std.container from a Design by
Introspection perspective
I've seen you use this
42 matches
Mail list logo
