On Fri, 12 Apr 2013 15:26:12 -0400, Tove <t...@fransson.se> wrote:
On Friday, 12 April 2013 at 15:43:27 UTC, Steven Schveighoffer wrote:
On Fri, 12 Apr 2013 04:14:15 -0400, Manu <turkey...@gmail.com>
I'd use string[].
You mean with format "a=b"? I suppose that's possible, though horrible
to work with before passing in. Plus what happens if you have ["a=b",
"a=c"] ? AA's prevent these kinds of mistakes/contradictions.
I prefer Manu's idea with the API accepting string[], it's closer to the
native format.
That's great for the library on POSIX systems, but for the user, it's not
as straightforward. One must construct "x=y" strings instead of setting x
to y. Unless you are using literals, this involves an allocation anyway.
Also, this is not the native format on Windows which passes the
environment in one large string delimited by nulls.
Then you could simply provide a convenience conversion from a map...
ex env!["foo" : "bar"] which would convert it to ["foo=bar"].
This also has the added benefit of being self documenting(considering
the lack of named parameters).
So for the most convenient/common case, you want to add an allocation?
But most importantly So the user has a free choice of constructing the
env parameter manually in the most efficient way or using the lazy
convenience function.
I think the best suggestion so far is to allow a templated version for
which you can provide an opIndex method, and a possible toEnv method
(versioned for both Posix and Windows of course). Then you have the power
to avoid allocation as much as possible. At the moment with AA's being
the interface, we have no possibility to avoid allocation, and I
understand that point. But I don't want to eliminate that case or make it
specifically more inefficient.
-Steve
