On Mon, Mar 02, 2020 at 07:51:34PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> On 3/2/20 6:46 PM, H. S. Teoh wrote:
> > To prevent the optimizer from eliding "useless" code, you need to do
> > something with the return value that isn't trivial (assigning to a
> > variable
On 3/2/20 7:32 PM, aliak wrote:
On Monday, 2 March 2020 at 23:27:22 UTC, Steven Schveighoffer wrote:
What I think is happening is that it determines nobody is using the
result, and the function is pure, so it doesn't bother calling that
function (probably not even the lambda, and then
On Monday, 2 March 2020 at 23:27:22 UTC, Steven Schveighoffer
wrote:
What I think is happening is that it determines nobody is using
the result, and the function is pure, so it doesn't bother
calling that function (probably not even the lambda, and then
probably removes the loop completely).
On Mon, Mar 02, 2020 at 06:27:22PM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> Yeah, this looked very fishy to me. ldc can do some nasty "helpful"
> things to save you time! When I posted my results, I was using DMD.
>
> I used run.dlang.io with ldc, and verified I get the
On 3/2/20 5:21 PM, aliak wrote:
On Monday, 2 March 2020 at 21:33:37 UTC, Steven Schveighoffer wrote:
On 3/2/20 3:52 PM, aliak wrote:
On Monday, 2 March 2020 at 15:47:26 UTC, Steven Schveighoffer wrote:
On 3/2/20 6:52 AM, Andrea Fontana wrote:
On Saturday, 29 February 2020 at 20:11:24 UTC,
On Monday, 2 March 2020 at 21:33:37 UTC, Steven Schveighoffer
wrote:
On 3/2/20 3:52 PM, aliak wrote:
On Monday, 2 March 2020 at 15:47:26 UTC, Steven Schveighoffer
wrote:
On 3/2/20 6:52 AM, Andrea Fontana wrote:
On Saturday, 29 February 2020 at 20:11:24 UTC, Steven
Schveighoffer wrote:
1. in
On 3/2/20 3:52 PM, aliak wrote:
On Monday, 2 March 2020 at 15:47:26 UTC, Steven Schveighoffer wrote:
On 3/2/20 6:52 AM, Andrea Fontana wrote:
On Saturday, 29 February 2020 at 20:11:24 UTC, Steven Schveighoffer
wrote:
1. in is supposed to be O(lg(n)) or better. Generic code may depend
on this
On Monday, 2 March 2020 at 15:47:26 UTC, Steven Schveighoffer
wrote:
On 3/2/20 6:52 AM, Andrea Fontana wrote:
On Saturday, 29 February 2020 at 20:11:24 UTC, Steven
Schveighoffer wrote:
1. in is supposed to be O(lg(n)) or better. Generic code may
depend on this property. Searching an array is
On Monday, 2 March 2020 at 15:50:08 UTC, Steven Schveighoffer
wrote:
On 3/2/20 6:39 AM, JN wrote:
On Saturday, 29 February 2020 at 21:56:51 UTC, Ali Çehreli
wrote:
Because you mentioned canFind, I think you want the semantics
to be "is there an element with this value." If so, it would
be
On 3/2/20 6:39 AM, JN wrote:
On Saturday, 29 February 2020 at 21:56:51 UTC, Ali Çehreli wrote:
Because you mentioned canFind, I think you want the semantics to be
"is there an element with this value." If so, it would be confusing to
use the same operator for two different things: For
On 3/2/20 6:52 AM, Andrea Fontana wrote:
On Saturday, 29 February 2020 at 20:11:24 UTC, Steven Schveighoffer wrote:
1. in is supposed to be O(lg(n)) or better. Generic code may depend on
this property. Searching an array is O(n).
Probably it should work if we're using a "SortedRange".
int[]
On Saturday, 29 February 2020 at 20:11:24 UTC, Steven
Schveighoffer wrote:
1. in is supposed to be O(lg(n)) or better. Generic code may
depend on this property. Searching an array is O(n).
Probably it should work if we're using a "SortedRange".
int[] a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
auto
On Saturday, 29 February 2020 at 21:56:51 UTC, Ali Çehreli wrote:
Because you mentioned canFind, I think you want the semantics
to be "is there an element with this value." If so, it would be
confusing to use the same operator for two different things:
For associative arrays, it means "is
On 2/29/20 11:38 AM, JN wrote:
> assert(1 in [1, 2, 3]);
Because you mentioned canFind, I think you want the semantics to be "is
there an element with this value." If so, it would be confusing to use
the same operator for two different things: For associative arrays, it
means "is there an
On 2/29/20 2:38 PM, JN wrote:
assert(1 in [1, 2, 3]);
Error: incompatible types for (1) in ([1, 2, 3]): int and int[
Yes, I know about .canFind(), but this is something that trips people
over and over.
I think it would be better if "in" worked for both assoc arrays and
normal arrays, or
15 matches
Mail list logo
