Initializing immutable structures is a source of constant grief. Anything
non-trivial requires instancing a mutable structure, initializing it, and
then either casting to immutable (it's up to you to ensure no alias
leaked) or, not to violate the type system, duplicate the whole.
Yet, if th
Dnia 18-10-2010 o 20:31:26 Tomek Sowiński napisał(a):
Initializing immutable structures is a source of constant grief.
Anything non-trivial requires instancing a mutable structure,
initializing it, and then either casting to immutable (it's up to you to
ensure no alias leaked) or, not to v
On Tue, 19 Oct 2010 14:54:32 -0400, Tomek Sowiński wrote:
OK, I see the interest is dying down (so boring, not even one duck to
name) so I filed an enhancement request so it won't be forgotten.
In this NG, no comments usually means nobody can find anything else wrong
with it, which is a go
Tomek S.:
> OK, I see the interest is dying down (so boring, not even one duck to
> name)
I didn't comment because I didn't have something useful to add to the
discussion. But a clean way to initialize immutable data structures is needed
in D. We have recently discussed this a little in the D
On Mon, 18 Oct 2010 14:31:26 -0400, Tomek Sowiński wrote:
Initializing immutable structures is a source of constant grief.
Anything non-trivial requires instancing a mutable structure,
initializing it, and then either casting to immutable (it's up to you to
ensure no alias leaked) or, not
Dnia 18-10-2010 o 20:53:15 Steven Schveighoffer
napisał(a):
On Mon, 18 Oct 2010 14:31:26 -0400, Tomek Sowiński wrote:
Initializing immutable structures is a source of constant grief.
Anything non-trivial requires instancing a mutable structure,
initializing it, and then either casting t
On Mon, 18 Oct 2010 15:20:39 -0400, Tomek Sowiński wrote:
Dnia 18-10-2010 o 20:53:15 Steven Schveighoffer
napisał(a):
On Mon, 18 Oct 2010 14:31:26 -0400, Tomek Sowiński wrote:
Initializing immutable structures is a source of constant grief.
Anything non-trivial requires instancing a mu
Dnia 18-10-2010 o 21:38:07 Steven Schveighoffer
napisał(a):
On Mon, 18 Oct 2010 15:20:39 -0400, Tomek Sowiński wrote:
[snip]
Anyway, if these immutable ctors are defined inside the type, then the
library writer may not provide a ctor suitable for your case (very
possible).
Yes true.
On 2010-10-18 14:31:26 -0400, Tomek Sowiński said:
Call me crazy, but I think it is safe to implicitly convert a pure
function's return value to immutable. What you think?
Well, it depends on the arguments of the pure function. Here's two
cases where it won't work.
1. With the new pure se
Michel Fortin wrote:
On 2010-10-18 14:31:26 -0400, Tomek Sowiński said:
Call me crazy, but I think it is safe to implicitly convert a pure
function's return value to immutable. What you think?
Well, it depends on the arguments of the pure function. Here's two cases
where it won't work.
[s
On 2010-10-18 17:05:27 -0400, Don said:
Michel Fortin wrote:
On 2010-10-18 14:31:26 -0400, Tomek Sowiński said:
Call me crazy, but I think it is safe to implicitly convert a pure
function's return value to immutable. What you think?
Well, it depends on the arguments of the pure function.
Dnia 18-10-2010 o 23:05:27 Don napisał(a):
Michel Fortin wrote:
On 2010-10-18 14:31:26 -0400, Tomek Sowiński said:
Call me crazy, but I think it is safe to implicitly convert a pure
function's return value to immutable. What you think?
Well, it depends on the arguments of the pure functi
On 2010-10-18 17:25:49 -0400, Tomek Sowiński said:
Thanks for support. I see two ways to go about it:
pure T make(Args args) { ... }
unittest {
T t = make(...); // good
immutable T t = make(...); // also good
}
Or:
pure immutable(T) make(Args args) {
T t = ...;
// initial
13 matches
Mail list logo
