On 3/23/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
WAT?! What on earth is cast() supposed to mean??
I've no idea. It's probably a front-end bug and the cast forces the
compiler to.. come to its senses?
On 23 March 2012 19:15, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
I've no idea. It's probably a front-end bug and the cast forces the
compiler to.. come to its senses?
`cast()` is the compiler equivalent to a slap with a wet fish?
--
James Miller
On 03/23/2012 01:24 AM, H. S. Teoh wrote:
WAT?! What on earth is cast() supposed to mean??
I think it removes one level of const or immutable from the type of its
argument. Why that helps in this case, I don't know.
--Ed
H. S. Teoh hst...@quickfur.ath.cx wrote in message
news:mailman.1036.1332480215.4860.digitalmar...@puremagic.com...
On Fri, Mar 23, 2012 at 06:11:05AM +0100, Andrej Mitrovic wrote:
[...]
Btw, want to see a magic trick? Put this into your hash:
this(AA)(AA aa)
if
On 03/23/2012 07:15 AM, Andrej Mitrovic wrote:
On 3/23/12, H. S. Teohhst...@quickfur.ath.cx wrote:
WAT?! What on earth is cast() supposed to mean??
I've no idea. It's probably a front-end bug and the cast forces the
compiler to.. come to its senses?
That part is not a bug, it is specified.
On 3/23/12, Timon Gehr timon.g...@gmx.ch wrote:
Maybe you are also missing that this is valid code:
int[] a = [1 : 2, 3 : 4];
What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
which is puzzling to me.
On 03/23/2012 09:10 PM, Andrej Mitrovic wrote:
On 3/23/12, Timon Gehrtimon.g...@gmx.ch wrote:
Maybe you are also missing that this is valid code:
int[] a = [1 : 2, 3 : 4];
What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
which is puzzling to me.
It creates an array
On 3/23/12, Timon Gehr timon.g...@gmx.ch wrote:
It creates an array from key-value pairs. a[1] will be 2 and a[3] will
be 4. Unspecified entries are default-initialized. It can be quite
useful for building lookup tables.
Interesting. It's documented under Static Initialization of
Statically
Andrej Mitrovic:
On 3/23/12, Timon Gehr timon.g...@gmx.ch wrote:
Maybe you are also missing that this is valid code:
int[] a = [1 : 2, 3 : 4];
What is this syntax for and how is it used? It creates '[0, 2, 0, 4]',
which is puzzling to me.
See:
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Sorry, I was thinking in terms of my AA implementation which is done
using a struct with operator overloading. I should've checked what the
behaviour of the current built-in AAs are before posting. :-P
Well in that case isn't it a necessity
On 21/03/12 21:41, Alvaro wrote:
El 21/03/2012 19:39, Jonathan M Davis escribió:
On Wednesday, March 21, 2012 11:29:14 H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
This is understandable, since the
On Wednesday, 21 March 2012 at 20:41:17 UTC, Alvaro wrote:
I partially disagree. I think items should be added if we try
to *write* to them, but not when we *read* them (lvalue vs
rvalue). The problem is that it's hard to distinguish those
cases in C++ without an intermediate class that makes
On 3/22/12, Jesse Phillips jessekphillip...@gmail.com wrote:
double[int] a;
What is the result of your code on 'a' now? double.init is NAN.
Hmm this is interesting. With 2.058:
double[int] a;
a[0]++;
writeln(a[0]); // prints 1
double b;
b++;
writeln(b); // prints nan
On Thu, Mar 22, 2012 at 11:01:35AM +0100, Andrej Mitrovic wrote:
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Sorry, I was thinking in terms of my AA implementation which is done
using a struct with operator overloading. I should've checked what the
behaviour of the current built-in
On Thu, Mar 22, 2012 at 03:26:00PM +0100, Andrej Mitrovic wrote:
On 3/22/12, Jesse Phillips jessekphillip...@gmail.com wrote:
double[int] a;
What is the result of your code on 'a' now? double.init is NAN.
Hmm this is interesting. With 2.058:
double[int] a;
a[0]++;
writeln(a[0]); //
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
This is because in aaA.d _aaGetX creates a new entry if one isn't found,
but because it has no direct access to value types (only has typeinfo),
it doesn't know what value .init has. It sets the value to binary zero
by default.
Damn, hashes
On 3/22/12 9:32 AM, H. S. Teoh wrote:
On Thu, Mar 22, 2012 at 11:01:35AM +0100, Andrej Mitrovic wrote:
On 3/21/12, H. S. Teohhst...@quickfur.ath.cx wrote:
Sorry, I was thinking in terms of my AA implementation which is done
using a struct with operator overloading. I should've checked what
Andrei Alexandrescu:
This is a bug in the language that requires fixing.
I agree. Is someone willing to write a good enhancement request
about it?
Bye,
bearophile
On Thu, Mar 22, 2012 at 03:48:24PM +0100, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
This is because in aaA.d _aaGetX creates a new entry if one isn't found,
but because it has no direct access to value types (only has typeinfo),
it doesn't know what value
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
You can check out the current code here:
https://github.com/quickfur/New-AA-implementation
I need Git Head (2.059) for this, right? Otherwise I get:
newAA.d(426): Error: inout on parameter means inout must be on return type
as well (if
On Thu, Mar 22, 2012 at 05:52:54PM +0100, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
You can check out the current code here:
https://github.com/quickfur/New-AA-implementation
I need Git Head (2.059) for this, right? Otherwise I get:
newAA.d(426):
On Thu, 22 Mar 2012 15:35:06 +0100, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Thu, Mar 22, 2012 at 03:26:00PM +0100, Andrej Mitrovic wrote:
On 3/22/12, Jesse Phillips jessekphillip...@gmail.com wrote:
double[int] a;
What is the result of your code on 'a' now? double.init is NAN.
Hmm
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Probably. I've been developing on 2.059 so I didn't realize there are
incompatibilities with earlier versions.
Your test files work ok. I'll test it on my own projects as soon as I
get rid of a few compilation errors (all of a sudden I get
On Thu, Mar 22, 2012 at 06:43:29PM +0100, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Probably. I've been developing on 2.059 so I didn't realize there
are incompatibilities with earlier versions.
Your test files work ok. I'll test it on my own projects as
On 3/22/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Your test files work ok.
Well unfortunately isAssociativeArray from std.traits fails on your
hashes (reasonable, since it calls __traits internally and has no way
of knowing about external hashes).
I also can't use your hashes with
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Yeah that's probably caused by a recent dmd change to soldier on after a
template instantiation error. :-)
Hopefully that gets fixed by the next release. Otherwise we can expect
an angry dev creating a D FQA site, heheh. :P
On Thu, Mar 22, 2012 at 07:04:09PM +0100, Andrej Mitrovic wrote:
On 3/22/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Your test files work ok.
Well unfortunately isAssociativeArray from std.traits fails on your
hashes (reasonable, since it calls __traits internally and has no way
On Thu, Mar 22, 2012 at 11:21:43AM -0700, H. S. Teoh wrote:
[...]
Hmm. Perhaps some aliases are in order?
struct AssociativeArray(K,V) {
...
alias Key keytype;
alias Value valuetype;
...
}
[...]
OK, I've added these
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
OK, I've added these aliases and pushed to github. I think they're a
useful thing to have. If not, it's easy to remove before we integrate
with druntime. But at least in the meantime it will make these AA's
easier to work with.
Could you
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
snip
Hmm, what about (temporary) compatibility with hash literals? You
could add the following to the newAA module:
static import std.traits;
template KeyType(V : V[K], K)
{
alias K KeyType;
}
template ValueType(V : V[K], K)
{
alias
On 22/03/12 18:43, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teohhst...@quickfur.ath.cx wrote:
Probably. I've been developing on 2.059 so I didn't realize there are
incompatibilities with earlier versions.
Your test files work ok. I'll test it on my own projects as soon as I
get rid of a few
On Thu, Mar 22, 2012 at 07:55:09PM +0100, Andrej Mitrovic wrote:
[...]
Hmm, what about (temporary) compatibility with hash literals? You
could add the following to the newAA module:
static import std.traits;
template KeyType(V : V[K], K)
{
alias K KeyType;
}
template ValueType(V :
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Maybe this needs a ctor?
Yeah probably. I really don't know when opAssign or the ctor are
called (especially with more complex types with alias this). Maybe
someone knows this or it's in the spec but I haven't read about it.
On Thu, Mar 22, 2012 at 04:31:00PM +0100, bearophile wrote:
Andrei Alexandrescu:
This is a bug in the language that requires fixing.
I agree. Is someone willing to write a good enhancement request
about it?
[...]
Done:
http://d.puremagic.com/issues/show_bug.cgi?id=7753
Please
On Thu, Mar 22, 2012 at 10:25:04PM +0100, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Maybe this needs a ctor?
Yeah probably. I really don't know when opAssign or the ctor are
called (especially with more complex types with alias this). Maybe
someone knows
On Thu, Mar 22, 2012 at 09:29:36PM -0700, H. S. Teoh wrote:
On Thu, Mar 22, 2012 at 10:25:04PM +0100, Andrej Mitrovic wrote:
On 3/22/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Maybe this needs a ctor?
Yeah probably. I really don't know when opAssign or the ctor are
called
On 3/23/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
I'm guessing the compiler thinks the literal is an array literal, or
maybe something went awry with the internal AA hacks that it currently
has.
struct Foo
{
string[int] aa;
alias aa this;
}
void main()
{
Foo x = [1 : 4];
}
On Fri, Mar 23, 2012 at 06:11:05AM +0100, Andrej Mitrovic wrote:
[...]
Btw, want to see a magic trick? Put this into your hash:
this(AA)(AA aa)
if (std.traits.isAssociativeArray!AA
is(KeyType!AA == keytype)
is(ValueType!AA == valuetype))
{
foreach (key, val; aa)
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
This is understandable, since the compiler translates the second line to:
map.opIndex(abc).opIndexUnary!++(20);
Since map[abc] doesn't exist yet, opIndex
On Wednesday, March 21, 2012 11:29:14 H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
This is understandable, since the compiler translates the second line to:
map.opIndex(abc).opIndexUnary!++(20);
On Wednesday, 21 March 2012 at 18:27:30 UTC, H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws
a
RangeError:
int[string][int] map;
map[abc][20]++;
Wait a second – aren't AAs _supposed_ to throw if accessing a
key that doesn't exist yet? To be
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
Comments?
Initially I was against hash[key]++ working on non-existent keys, but
I've changed my mind about this. However it still throws me off that
hash[key1][key2]++ doesn't work if key1 doesn't exist.
So you get a +1 vote from me.
On 3/21/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
I think that the current behavior is very much what the behavior _should_ be.
But the current behavior is already at odds. This already works:
int[string] foo;
foo[bar]++;
On Wed, Mar 21, 2012 at 02:39:04PM -0400, Jonathan M Davis wrote:
[...]
IMHO, it's _horrible_ that C++ creates entries in a std::map when you
ask for values that aren't there. A RangeError is _exactly_ what
should be happening here. There's no element to increment, because it
hasn't been added
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
int[string][int] map;
map[abc] = int[int].init;
map[abc][30] = 123;
I think you meant:
int[int][string] map;
map[abc] = (int[int]).init;
map[abc][30] = 123;
You can however init with null if the value is a
On Wed, Mar 21, 2012 at 07:29:44PM +0100, David Nadlinger wrote:
On Wednesday, 21 March 2012 at 18:27:30 UTC, H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
Wait a second – aren't AAs
On 03/21/2012 11:29 AM, H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
Hey! That syntax is following the broken syntax of C and C++. ;)
This works:
import std.stdio;
void main()
{
On 3/21/12, Ali Çehreli acehr...@yahoo.com wrote:
This works:
For some reason thought it didn't work without double-checking. Heh. :p
On Wed, Mar 21, 2012 at 07:56:47PM +0100, Andrej Mitrovic wrote:
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
int[string][int] map;
map[abc] = int[int].init;
map[abc][30] = 123;
I think you meant:
int[int][string] map;
map[abc] = (int[int]).init;
H. S. is making a Library replacement AA and is what his example
is concerned with.
You are correct, it seems his example has it out of order, the
example on Learn was
int[100][string] map;
...
On Wednesday, 21 March 2012 at 18:58:34 UTC, Ali Çehreli wrote:
This works:
import std.stdio;
On Wed, 21 Mar 2012 14:29:14 -0400, H. S. Teoh hst...@quickfur.ath.cx
wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
This is understandable, since the compiler translates the second line to:
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
whereas if this was supported, the code would simply be:
void inc_frequency(string entry, int xcoor, int ycoor) {
map[entry][x][y]++;
}
Wait a minute. Are we missing something? This does work in 2.058:
void
El 21/03/2012 19:29, H. S. Teoh escribió:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
IIRC, that worked fine for me a few weeks ago. And I found it to be just
great that it did. I'll have to re-check but
El 21/03/2012 19:39, Jonathan M Davis escribió:
On Wednesday, March 21, 2012 11:29:14 H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
map[abc][20]++;
This is understandable, since the compiler translates the second line to:
On Wednesday, March 21, 2012 12:00:36 H. S. Teoh wrote:
On Wed, Mar 21, 2012 at 07:29:44PM +0100, David Nadlinger wrote:
On Wednesday, 21 March 2012 at 18:27:30 UTC, H. S. Teoh wrote:
A question was asked on the d-learn forum about why this throws a
RangeError:
int[string][int] map;
On Wed, Mar 21, 2012 at 09:25:04PM +0100, Andrej Mitrovic wrote:
On 3/21/12, H. S. Teoh hst...@quickfur.ath.cx wrote:
whereas if this was supported, the code would simply be:
void inc_frequency(string entry, int xcoor, int ycoor) {
map[entry][x][y]++;
}
Wait a
On Wed, Mar 21, 2012 at 05:21:22PM -0400, Jonathan M Davis wrote:
On Wednesday, March 21, 2012 12:00:36 H. S. Teoh wrote:
[...]
But perhaps that was the wrong example to use. What if you wanted to
do this:
map[abc][20] = 1;
Currently this doesn't work. You have to explicitly create
On 3/21/12 5:44 PM, H. S. Teoh wrote:
Sorry, I was thinking in terms of my AA implementation which is done
using a struct with operator overloading. I should've checked what the
behaviour of the current built-in AAs are before posting. :-P
The request for autovivification (believe it or not,
On Wednesday, March 21, 2012 15:52:58 H. S. Teoh wrote:
On Wed, Mar 21, 2012 at 05:21:22PM -0400, Jonathan M Davis wrote:
On Wednesday, March 21, 2012 12:00:36 H. S. Teoh wrote:
[...]
But perhaps that was the wrong example to use. What if you wanted to
do this:
map[abc][20] = 1;
59 matches
Mail list logo
