On 10/30/17 6:49 AM, Tony wrote:
I prefer the built-in associative array over using some template
library. It has the clean look and ease-of-use that you get with a
similar data structure in dynamic languages like Python. I consider it a
top feature of D.
There is a misunderstanding here. The
I prefer the built-in associative array over using some template
library. It has the clean look and ease-of-use that you get with
a similar data structure in dynamic languages like Python. I
consider it a top feature of D.
On Sunday, October 29, 2017 22:24:57 Nordlöw via Digitalmars-d-learn wrote:
> Shouldn't associative arrays with key types (K) having mutable
> indirections (std.traits.hasAliasing!K) such as
>
> string[ubyte[]]
>
> be disallowed?
>
> If not, in what cases do we want this?
Well, the built-in a
On Tuesday, 10 November 2015 at 01:29:11 UTC, Brian Schott wrote:
Yes. It's a hack that gives you a modulus without having to do
a modulus. It only works on powers of two.
http://graphics.stanford.edu/~seander/bithacks.html#ModulusDivisionEasy
On Monday, 9 November 2015 at 21:33:09 UTC, TheFlyingFiddle wrote:
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/e
On Monday, 9 November 2015 at 21:33:09 UTC, TheFlyingFiddle wrote:
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/e
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/economicmodeling/containers
I have a question regarding the impleme
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
[...]
Nope.
[...]
As far as I'm aware, you are stuck using e.g. structs to
emulate AA behavior.
I have a VERY basic imp
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
[...]
Nope.
[...]
As far as I'm aware, you are stuck using e.g. structs to
emulate AA behavior.
I have a VERY basic implementation here:
https://github.com/rikkimax/alphaPhobos
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
I have a few questions about the pseudo built in associative arrays.
1. Is it possible to have the built in associative array use a custom
allocator from std.experimental.allocator to service it's allocation needs?
Nope.
2. A while ago I read on th
On Saturday, 12 April 2014 at 09:18:12 UTC, bearophile wrote:
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
Related: "Rebindable supports arrays (Which makes no sense)"
https://issues.dlang.org/show_bug.cgi?id=12046
Q
On Saturday, 12 April 2014 at 09:18:12 UTC, bearophile wrote:
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
May be just like Rebindable for classes?
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
dennis luehring wrote:
> so your FileDelete would not return an FileDoesNotExists-Error?
Correct.
> would it not help to better understand big code if the remove
> would be renamed to remove_existing or to add something like this?
Maybe.
You possibly know about the `rm'-command of *nix-like sys
Am 09.01.2012 22:08, schrieb Manfred Nowak:
dennis luehring wrote:
why is there an exception/error neeeded if missing?
Exceptions or errors are not _needed_.
Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
dennis luehring wrote:
> why is there an exception/error neeeded if missing?
Exceptions or errors are not _needed_.
Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
is
a:only the outcome of the operation or
On 1/9/12, Steven Schveighoffer wrote:
> Could this be you?
Ah, yes. I didn't even notice you've replied to that, sorry. Yes, I'm
ok with it.
On Mon, 09 Jan 2012 14:57:36 -0500, Andrej Mitrovic
wrote:
Ok, allow me to temporarily hijack again and ask: Would you mind
adding opIn_r (or rather the newer opBinaryRight with "in") that
forwards to contains() for the HashSet and similar hash-based classes
that define contains()? It would m
Ok, allow me to temporarily hijack again and ask: Would you mind
adding opIn_r (or rather the newer opBinaryRight with "in") that
forwards to contains() for the HashSet and similar hash-based classes
that define contains()? It would make porting code that uses builtin
hashes to your own implementat
On Mon, 09 Jan 2012 13:35:26 -0500, Andrej Mitrovic
wrote:
On 1/9/12, Steven Schveighoffer wrote:
BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that
adding elements does not invalidated cursors (dcollections' safe version
of pointers) as long as you use the default Hash
On 1/9/12, Steven Schveighoffer wrote:
> BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that
> adding elements does not invalidated cursors (dcollections' safe version
> of pointers) as long as you use the default Hash implementation. However,
> I just noticed this is not stat
On Monday, January 09, 2012 09:25:14 Steven Schveighoffer wrote:
> Actually, not invalid for the current implementation. I don't know if
> it's stated whether an AA specifically requires that elements do not
> re-associate on a rehash.
Well, like I said, it depends on the current implementation. T
On Sun, 08 Jan 2012 08:40:27 -0500, Jonathan M Davis
wrote:
On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
Thanks for your clarifications.
Does this mean even this is undefined?
aa["a"] = new C();
auto c = "a" in aa;
aa["b"] = new C();
// Using c here is undefined as an element was a
assert(key in aa);
aa.remove(key);
So, as far as I can tell, the current situation is more efficient, and it
doesn't cost you any expressiveness. You can still have an exception thrown
when remove fails if you use enforce before the call if you want an exception
thrown when the element isn't ther
Looks like this is fixed for 2.058.
https://github.com/D-Programming-Language/dmd/commit/3e23b0f5834acb32eaee20d88c30ead7e03bb2f4
On 08/01/2012 3:43 AM, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming
Very interesting discussion. Tk u all.
Based on these arguments does that mean std.file.remove should
not be throwing when a file doesn't exist?
Or more precisely should I add a bugzilla entry to change this. I
certainly have a lot of if(exists) remove() in my code and end up
having to change where I just use remove().
On Sunday,
On Sunday, January 08, 2012 14:57:51 simendsjo wrote:
> On 08.01.2012 14:40, Jonathan M Davis wrote:
> > On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
> >> Thanks for your clarifications.
> >>
> >> Does this mean even this is undefined?
> >> aa["a"] = new C();
> >> auto c = "a" in aa;
> >>
On 08.01.2012 14:40, Jonathan M Davis wrote:
On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
Thanks for your clarifications.
Does this mean even this is undefined?
aa["a"] = new C();
auto c = "a" in aa;
aa["b"] = new C();
// Using c here is undefined as an element was added to aa
Yes. D
Jonathan M Davis wrote:
> In this case, it's very much like dealing with C++ iterators
A relevant part of Andrei's thread on "associative arrays iteration":
http://www.digitalmars.com/d/archives/digitalmars/D/associative_arrays_
iteration_is_finally_here_99576.html#N99614
-manfred
On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
> Thanks for your clarifications.
>
> Does this mean even this is undefined?
> aa["a"] = new C();
> auto c = "a" in aa;
> aa["b"] = new C();
> // Using c here is undefined as an element was added to aa
Yes. Depending on the current implementat
On 08.01.2012 13:49, Jonathan M Davis wrote:
On Sunday, January 08, 2012 13:06:06 simendsjo wrote:
Certainly not obvious to me :)
Well, what's obvious to one person is not always obvious to another. I'm sure
that there are plenty of things that Walter thinks should be perfectly obvious
which 9
On Sunday, January 08, 2012 13:06:06 simendsjo wrote:
> Certainly not obvious to me :)
Well, what's obvious to one person is not always obvious to another. I'm sure
that there are plenty of things that Walter thinks should be perfectly obvious
which 90% of programmers would never think of. A lot
On 08.01.2012 12:57, Jonathan M Davis wrote:
On Sunday, January 08, 2012 12:35:27 simendsjo wrote:
On 08.01.2012 12:18, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
I was thinking it could be a shorthand for the following:
auto item = key in aa;
if (item) key.
On Sunday, January 08, 2012 12:35:27 simendsjo wrote:
> On 08.01.2012 12:18, Jonathan M Davis wrote:
> > On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
> >> I was thinking it could be a shorthand for the following:
> >>
> >> auto item = key in aa;
> >> if (item) key.remove(key);
> >
> > I
On 08.01.2012 12:18, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
I was thinking it could be a shorthand for the following:
auto item = key in aa;
if (item) key.remove(key);
I take it that you then intend to use item after that? I'm not sure that item
is actua
simendsjo wrote:
> it doesn't state return value
Yes, I haven't read carefully enough.
-manfred
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
> I was thinking it could be a shorthand for the following:
>
> auto item = key in aa;
> if (item) key.remove(key);
I take it that you then intend to use item after that? I'm not sure that item
is actually valid at that point. It points to me
On 1/8/12, simendsjo wrote:
> Wouldn't it make sense to return a pointer to the item being
> removed/null?
Seems like that would be even more costly. Personally I think
returning bool is unnecessary, if we really want to know if something
is in the hash we can check with the `in` operator.
I fil
On 08.01.2012 11:27, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:02:41 simendsjo wrote:
On 08.01.2012 10:43, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.p
On Sunday, January 08, 2012 11:02:41 simendsjo wrote:
> On 08.01.2012 10:43, Jonathan M Davis wrote:
> > On Sunday, January 08, 2012 03:24:22 Kapps wrote:
> >> Ah, found the bug / pull request.
> >>
> >> https://github.com/D-Programming-Language/dmd/pull/597
> >> http://d.puremagic.com/issues/show
On 08.01.2012 11:09, Manfred Nowak wrote:
simendsjo wrote:
Wouldn't it make sense to return a pointer to the item being
removed/null?
According to the docs this is the intended behavior.
-manfred
The only mention I can see of remove is at the top, and it doesn't state
return value: http:/
simendsjo wrote:
> Wouldn't it make sense to return a pointer to the item being
> removed/null?
According to the docs this is the intended behavior.
-manfred
On 08.01.2012 10:43, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.puremagic.com/issues/show_bug.cgi?id=4523
Ah, TDPL says that it returns bool. Well, then it definite
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
> Ah, found the bug / pull request.
>
> https://github.com/D-Programming-Language/dmd/pull/597
> http://d.puremagic.com/issues/show_bug.cgi?id=4523
Ah, TDPL says that it returns bool. Well, then it definitely needs to be
changed, and it's good to
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.puremagic.com/issues/show_bug.cgi?id=4523
On 08/01/2012 1:39 AM, Kapps wrote:
For most languages (such as C# and maybe Java), the Remove method on
collections returns a boolean indicating whether i
On Sunday, January 08, 2012 01:39:24 Kapps wrote:
> For most languages (such as C# and maybe Java), the Remove method on
> collections returns a boolean indicating whether it was removed. So you
> could write:
>
> enforce(MyAA.remove("lenght"))
> or
> bool Result = MyAA.remove("lenght");
> assert(
On 1/7/2012 8:54 PM, bearophile wrote:
>> Yes, Jonathan, you're right.
>> the question arose precisely from a typo... i had to remove an
>> item with key "length"... i wrote "lengt" and the item never went
>> away... i knew that "lengt" was not in my key list... This kind of
>> mistake is quite tri
For most languages (such as C# and maybe Java), the Remove method on
collections returns a boolean indicating whether it was removed. So you
could write:
enforce(MyAA.remove("lenght"))
or
bool Result = MyAA.remove("lenght");
assert(Result);
I'm not sure why it doesn't in D, but I thought I rem
Jonathan M Davis wrote:
> So, as far as I can tell, the current situation is more efficient
There are some more arguments:
1) Different threads might want to `remove' the same key from the AA. I
don't see a reason why only the first served thread should complete the
operation without an error.
On Saturday, January 07, 2012 21:54:07 bearophile wrote:
> Maybe D associative arrays too should have both kinds of deleting methods
> :-)
Why? What's the gain? If you care that the element is already in the AA, then
do either
assert(key in aa);
aa.remove(key);
or
enforce(key in aa);
aa.remove
RenatoL:
> Yes, Jonathan, you're right.
> the question arose precisely from a typo... i had to remove an
> item with key "length"... i wrote "lengt" and the item never went
> away... i knew that "lengt" was not in my key list... This kind of
> mistake is quite tricky, may be using and IDE could he
Yes, Jonathan, you're right.
the question arose precisely from a typo... i had to remove an
item with key "length"... i wrote "lengt" and the item never went
away... i knew that "lengt" was not in my key list... This kind of
mistake is quite tricky, may be using and IDE could help.
On Sunday, January 08, 2012 00:13:12 Manfred Nowak wrote:
> Jonathan M Davis wrote:
>
> [...]
>
> This sort of explanation is missing in the docs.
Which part?
- Jonathan M Davis
Jonathan M Davis wrote:
[...]
This sort of explanation is missing in the docs.
-manfred
On Saturday, January 07, 2012 23:34:05 RenatoL wrote:
> Yes, i agree this may acceptable. On the other hand if i really
> want/have to remove an item i have to be very careful cause a
> trivial typo could cause a disaster
In general, if an element isn't in a container, and you expect it to be
On Saturday, January 07, 2012 15:06:30 Ali Çehreli wrote:
> On 01/07/2012 02:11 PM, RenatoL wrote:
> > Very quick question
> >
> > import std.stdio;
> > void main()
> > {
> >
> >auto arr1 = ["uno":1, "due":2, "tre":3];
> >arr1.remove("xxx");
> >
> > }
> >
> > also in this ca
Yes, i agree this may acceptable. On the other hand if i really
want/have to remove an item i have to be very careful cause a
trivial typo could cause a disaster
RenatoL wrote:
> Would not it be better if an exception was raised?
No, because exceptions are guarenteed to be slow.
> if i write: writeln(arr1["xxx"]);
> runtime expresses its disappointment...
I would be disappointed too, if the commands for removing and for
requesting something are sequence
On 01/07/2012 02:11 PM, RenatoL wrote:
> Very quick question
>
> import std.stdio;
> void main()
> {
>auto arr1 = ["uno":1, "due":2, "tre":3];
>arr1.remove("xxx");
> }
>
> also in this case the compiler does not say anything and the
> program goes out silently ... why? Would not it be bett
Robert Clipsham:
> I was under the impression that associative arrays now used ?: to find
> the best type for the array? Or was this change only made in D2?
I think the change was for D2. (In my opinion D1 language is supposed to not go
on for lot of more time).
Bye,
bearophile
On Wed, 06 Oct 2010 08:12:28 -0400, bearophile
wrote:
Steven Schveighoffer:
Casting to immutable is the only way to create such a beast.
Then maybe we have to improve the language semantics to allow a better
solution. See the Transients of Clojure or the larval objects of Java :-)
The
Steven Schveighoffer:
> Casting to immutable is the only way to create such a beast.
Then maybe we have to improve the language semantics to allow a better
solution. See the Transients of Clojure or the larval objects of Java :-)
The compiler may need to test (at compile time) that there's only
On Tue, 05 Oct 2010 22:02:30 -0400, bearophile
wrote:
Denis Koroskin:
Compute mutable copy and then cast to immutable. Am I missing something?
That's possible. But it's an exceptionally dirty thing, I am not sure it
works in SafeD. A well designed const system has to offer a more clean
On Wed, 06 Oct 2010 06:02:30 +0400, bearophile
wrote:
Denis Koroskin:
Compute mutable copy and then cast to immutable. Am I missing something?
That's possible. But it's an exceptionally dirty thing, I am not sure it
works in SafeD. A well designed const system has to offer a more clean
Denis Koroskin:
> Compute mutable copy and then cast to immutable. Am I missing something?
That's possible. But it's an exceptionally dirty thing, I am not sure it works
in SafeD. A well designed const system has to offer a more clean solution :-)
Do you agree?
Bye,
bearophile
On Wed, 06 Oct 2010 04:14:37 +0400, bearophile
wrote:
Denis Koroskin:
I found the following to work fine:
K[V] assocArray = createAssocArray();
K[V] createAssocArray()
{
K[V] assocArray = [
k1: v1,
k2: v2,
...
];
return assocArray;
}
Thank you for
Denis Koroskin:
> I found the following to work fine:
>
> K[V] assocArray = createAssocArray();
>
> K[V] createAssocArray()
> {
> K[V] assocArray = [
> k1: v1,
> k2: v2,
> ...
> ];
>
> return assocArray;
> }
Thank you for your answer. But I need to comput
On Wed, 06 Oct 2010 03:45:11 +0400, bearophile
wrote:
/*immutable*/ E_MODE[string] a_mode;
static this () {
foreach (m; __traits(allMembers, E_MODE))
mixin(`a_mode["` ~ m ~ `"] = E_MODE.` ~ m ~ `;`);
}
How do you build an immutable AA that is global or local to a function?
Bye
> /*immutable*/ E_MODE[string] a_mode;
>
> static this () {
> foreach (m; __traits(allMembers, E_MODE))
> mixin(`a_mode["` ~ m ~ `"] = E_MODE.` ~ m ~ `;`);
> }
How do you build an immutable AA that is global or local to a function?
Bye,
bearophile
> enum E_MODE {
> LSB, // 0
> USB, // 1
> DSB, // 2
> CWL, // 3
> CWU, // 4
> FMN, // 5
> AM, // 6
> DIGU, // 7
> SPEC, // 8
> DIGL, // 9
> SAM, // 10
> DRM // 11
> }
>
> void main() {
> // associative array for translation
>
Denis Koroskin:
> import std.stdio;
> import std.typecons;
>
> void main()
> {
> auto aa = ["hello": tuple(100.0, 6100.0)];
> auto result = aa["hello"];
>
> writeln(result.field[0], " ", result._1); // primary and alternative way
> }
Now Tuples accept the natural syntax
On 05/10/2010 15:14, Steven Schveighoffer wrote:
> On Tue, 05 Oct 2010 09:00:13 -0400, Bob Cowdery
> wrote:
>
>> On 05/10/2010 13:45, Denis Koroskin wrote:
>
>>> "static this" is called a static constructor and can be used for
>>> classes and modules. The code in static constructor is guarantied
On Tue, 05 Oct 2010 09:00:13 -0400, Bob Cowdery
wrote:
On 05/10/2010 13:45, Denis Koroskin wrote:
"static this" is called a static constructor and can be used for
classes and modules. The code in static constructor is guarantied to
be called before you use that class/module, it usually ha
On Tue, 05 Oct 2010 17:00:13 +0400, Bob Cowdery
wrote:
On 05/10/2010 13:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 16:32:14 +0400, Bob Cowdery
wrote:
On 05/10/2010 13:05, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:53:55 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 05
On 05/10/2010 13:45, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 16:32:14 +0400, Bob Cowdery
> wrote:
>
>> On 05/10/2010 13:05, Denis Koroskin wrote:
>>> On Tue, 05 Oct 2010 15:53:55 +0400, Denis Koroskin <2kor...@gmail.com>
>>> wrote:
>>>
On Tue, 05 Oct 2010 15:40:39 +0400, Bob Cowdery
>>>
On Tue, 05 Oct 2010 16:32:14 +0400, Bob Cowdery
wrote:
On 05/10/2010 13:05, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:53:55 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 05 Oct 2010 15:40:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05
On 05/10/2010 13:05, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 15:53:55 +0400, Denis Koroskin <2kor...@gmail.com>
> wrote:
>
>> On Tue, 05 Oct 2010 15:40:39 +0400, Bob Cowdery
>> wrote:
>>
>>> On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
On Tue, 05 Oct 2010 15:53:55 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tue, 05 Oct 2010 15:40:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue,
On Tue, 05 Oct 2010 12:50:44 +0100, Bob Cowdery wrote:
> On 05/10/2010 12:40, Bob Cowdery wrote:
>> On 05/10/2010 12:13, Denis Koroskin wrote:
>>> On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
>>> wrote:
>>>
On 05/10/2010 12:04, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 14:57:22 +0
On Tue, 05 Oct 2010 15:50:44 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:40, Bob Cowdery wrote:
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
On Tue, 05 Oct 2010 15:40:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
wrote:
On 05/10/2010 11:45, Denis Koro
On 05/10/2010 12:40, Bob Cowdery wrote:
> On 05/10/2010 12:13, Denis Koroskin wrote:
>> On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
>> wrote:
>>
>>> On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
wrote:
> On 05/10/2010 11:45,
On 05/10/2010 12:13, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
> wrote:
>
>> On 05/10/2010 12:04, Denis Koroskin wrote:
>>> On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
>>> wrote:
>>>
On 05/10/2010 11:45, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 14:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
wrote:
I can't seem to get any sense o
On 05/10/2010 12:04, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
> wrote:
>
>> On 05/10/2010 11:45, Denis Koroskin wrote:
>>> On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
>>> wrote:
>>>
I can't seem to get any sense out of associative arrays. Even the
s
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
On 05/10/2010 11:45, Denis Koroskin wrote:
> On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
> wrote:
>
>> I can't seem to get any sense out of associative arrays. Even the
>> simplest definition won't compile so I must be doing something daft.
>>
>> int[string] aa = ["hello":42];
>>
>> Error: n
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = ["hello":42];
Error: non-constant expression ["hello":42]
What exactly is not cons
Hello Mario,
But then, JSON has a jew more unspecified gaps like "whitespace can be
inserted between any pair of tokens".
That can be dealt with by just being consistent.
Shall we rely on the fact that the implementation currently does not
insert whitespace between tokens?
On the output s
> >> the correct solution is to make the check order independent. For
> >> example:
> >> string s = CallReturningJSON();
> >> s = replace(s,`"a":23.54`, `X`);
> >> s = replace(s,`"b":0.0012`, `X`);
> >> s = replace(s,`{"nested":{X,X}}`, `X`);
> >> s = replace(s,`"goodbye":[true,"or",false,["test",4
Hello Mario,
Unless JSON requiers that the keys be in some order,
No, JSON does not require the names of an object to be in alphabetical
order.
the correct solution is to make the check order independent. For
example:
string s = CallReturningJSON();
s = replace(s,`"a":23.54`, `X`);
s = repla
> Unless JSON requiers that the keys be in some order,
No, JSON does not require the names of an object to be in alphabetical order.
> the correct solution is to make the check order independent. For example:
> string s = CallReturningJSON();
> s = replace(s,`"a":23.54`, `X`);
> s = replace(s,`"b
Hello Mario,
That is, shall we produce "canonical" JSON text at the price of
efficiency.
Or, shall the perfect implementation of JSON objects as associative
arrays be dropped?
Or, what else?
Unless JSON requiers that the keys be in some order, the correct solution
is to make the check ord
MLT:
> Why is that?
I think this is the right syntax (I am using Phobos on D1):
import std.stdio: writefln;
void main() {
int[5][string] aa = ["a": [1, 2, 3, 4, 5]];
aa["b"][] = aa["a"]; # line 5
writefln(aa);
}
But it gives an:
Error: ArrayBoundsError temp(5)
It looks like a bug. St
95 matches
Mail list logo
