On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
On Tuesday, 23 June 2015 at 20:31:08 UTC, Jeremy Powers wrote:
Well I don't like assertions either, for specifically that
reason. An error is an error, I don't want something to be
caught and handled in debug to then be ignored and explode on
release. If my release isn't checking for it, and
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
Please no.
Different behavior between release and non is not
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
On Mon, Jun 22, 2015 at 8:39 PM, philippecp via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I think the best approach is the following:
* Throw exceptions on debug (usability)
* Leave undefined on release (performance)
On Tue, Jun 23, 2015 at 12:31 PM, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 June 2015 at 19:13:43 UTC, Jeremy Powers wrote:
Different behavior between release and non is not something to be desired.
It's perfectly normal if we're talking about
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
1. Leave it undefined, like the STL does. Probably this is too
extreme.
I don't think this is too extreme at all. If std.collections is
slow, nobody will use it.
If you don't believe me, go to code.dlang.org and ctrl+f json
On Tue, 23 Jun 2015 13:30:52 -0700, Jeremy Powers via Digitalmars-d wrote:
Well I don't like assertions either, for specifically that reason. An
error is an error, I don't want something to be caught and handled in
debug to then be ignored and explode on release. If my release isn't
On Monday, 22 June 2015 at 13:42:41 UTC, Steven Schveighoffer
wrote:
On 6/22/15 2:27 AM, Joseph Cassman wrote:
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
[...]
I was trying to understand how it could work with array
slices. For
example, I was thinking of code
On 6/21/15 10:03 PM, Steven Schveighoffer wrote:
On 6/21/15 10:55 PM, Andrei Alexandrescu wrote:
On 6/21/15 7:31 PM, Steven Schveighoffer wrote:
On 6/21/15 7:02 PM, Andrei Alexandrescu wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
On 6/22/15 2:29 AM, Andrei Alexandrescu wrote:
On 6/21/15 10:03 PM, Steven Schveighoffer wrote:
An iterator remains valid as long as its target hasn't been removed.
The matter is very well understood. My point here is that leaving it to
the user to make sure which ranges are still valid vs.
On Monday, 22 June 2015 at 06:29:20 UTC, Andrei Alexandrescu
wrote:
The matter is very well understood. My point here is that
leaving it to the user to make sure which ranges are still
valid vs. not is not appropriate for D's container. -- Andrei
Have you considered checking it at compile
On Monday, 22 June 2015 at 06:29:20 UTC, Andrei Alexandrescu
wrote:
The matter is very well understood. My point here is that
leaving it to the user to make sure which ranges are still
valid vs. not is not appropriate for D's container. -- Andrei
If we mean that we don't want undefined
On 6/22/15 2:27 AM, Joseph Cassman wrote:
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
Consider a traditional container with reference semantics, Java-style.
Regarding
On Sunday, 21 June 2015 at 23:02:38 UTC, Andrei Alexandrescu
wrote:
While I work on making std.allocator better, here's some food
for thought regarding std.collection.
Consider a traditional container with reference semantics,
Java-style. Regarding changing the collection (e.g.
On 6/21/15 4:55 PM, H. S. Teoh via Digitalmars-d wrote:
1. Leave it undefined, like the STL does. Probably this is too
extreme.
It may be extreme, but it also seems sanest, since it avoids treading in
the dangerous territory of strange and counterintuitive behaviours when
a container is
On Sunday, 21 June 2015 at 23:58:38 UTC, H. S. Teoh wrote:
On Sun, Jun 21, 2015 at 04:02:43PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
3. Allow the removal but throw from the ranges if there's any
attempt to use a range following a remove.
This is also too extreme. If I'm iterating
On 6/21/15 7:31 PM, Steven Schveighoffer wrote:
On 6/21/15 7:02 PM, Andrei Alexandrescu wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
Consider a traditional container with reference semantics, Java-style.
Regarding changing the
On 6/21/15 7:02 PM, Andrei Alexandrescu wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
Consider a traditional container with reference semantics, Java-style.
Regarding changing the collection (e.g. adding/removing elements) while
On 6/21/15 10:55 PM, Andrei Alexandrescu wrote:
On 6/21/15 7:31 PM, Steven Schveighoffer wrote:
On 6/21/15 7:02 PM, Andrei Alexandrescu wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
Consider a traditional container with reference
On Sun, Jun 21, 2015 at 04:02:43PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
While I work on making std.allocator better, here's some food for
thought regarding std.collection.
Consider a traditional container with reference semantics, Java-style.
Regarding changing the collection
23 matches
Mail list logo
