On Fri, 08 Apr 2011 16:12:27 -0400, spir wrote:
On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
In reality, most times you are not using something as a key and
somewhere else
simultaneously. So while theoretically dangerous, it's easy to write
code that
isn't dangerous.
What about
On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 14:57:52 -0400, spir wrote:
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[ch
On Fri, 08 Apr 2011 14:57:52 -0400, spir wrote:
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following do
On 04/08/2011 03:40 PM, Denis Koroskin wrote:
What about storing objects as keys? There is nothing wrong to modify those
objects as long as their order stays the same.
I think if referenced objects are to be used as keys, they should be compared
by pointer/identity (hash would return their add
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car = "hello";
What is the
On Fri, 08 Apr 2011 17:40:32 +0400, Denis Koroskin wrote:
> int compare(char[] lhs, char[] rhs) pure {
> if (lhs < rhs) return 1;
> if (lhs > rhs) return -1;
> return 0;
> }
>
> is not.
>
> For some reason (bug?), both compile with 2.052.
Purity has nothing to do with the type. "
On Fri, 08 Apr 2011 09:40:32 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Fri, 08 Apr 2011 17:13:19 +0400, Steven Schveighoffer
wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char
On Fri, 08 Apr 2011 17:13:19 +0400, Steven Schveighoffer
wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car =
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car = "hello";
What is the explanation for this behaviour?
The first sh
Of course, by saying it should not compile I mean
things like asr["hello"] should not compile.
On Fri, 08 Apr 2011 13:37:10 +0200, Morlan wrote:
int[char[]] is consistently used D's Language
reference to illustrate associative arrays. For me it
looks like something that should not compile. Of
course int[string] works without problem so I wonder
why int[char[]] was used as an example. Was
int[char[]] is consistently used D's Language
reference to illustrate associative arrays. For me it
looks like something that should not compile. Of
course int[string] works without problem so I wonder
why int[char[]] was used as an example. Was it carried
over from D1 reference perhaps?
On Fri, 08 Apr 2011 13:01:41 +0200, simendsjo
wrote:
It is a mistake to use non-immutable keys for an associative array.
But a string literal isn't mutable..?
This is correct. I'm referring to line 1, int[char[]] asr;. This
declaration is wrong, and should be rejected by the compiler.
Al
> It is a mistake to use non-immutable keys for an associative array.
But a string literal isn't mutable..?
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan wrote:
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car = "hello";
What is the explanation for this behaviour?
The first should not be allowed. It is a mistake to use non-immutable
keys
It is OK if I write
int[char[]] asr;
asr["hello"] = 10;
but the following does not compile:
char[] car = "hello";
What is the explanation for this behaviour?
16 matches
Mail list logo
