Hi,

I have some problems with adopting my code to a breaking change introduced in version 2.063. Apparently, now it's not anymore possible to instantiate an immutable object via:

auto object = new immutable(SomeClass)(contructor_args...);

without also defining either

this(constructor_args...) immutable {...}

or

this(constructor_args...) pure {...}


As much as I think that this change will make the system more consistent, I don't know how to fix my code. Often, in a constructor you pass other objects (via constructor dependency injection), and it seems that I have to fix a hell of a lot of dependency code that way. Is there a simple way of emulating the way it "just magically worked" in version 2.062?

For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?

Thanks,

Stephan

On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels <stephan_schiffels@mac.com> wrote:

> For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?

In std.exception there is assumeUnique. It's basically just a cast, but
might be good enough for you.

-- 
Simen

On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
> On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels <stephan_schiffels@mac.com> wrote:
>
>> For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?
>
> In std.exception there is assumeUnique. It's basically just a cast, but
> might be good enough for you.

I see, will look at that. I actually need it immutable since I am using it across multiple threads.

On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
> On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels <stephan_schiffels@mac.com> wrote:
>
>> For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?
>
> In std.exception there is assumeUnique. It's basically just a cast, but
> might be good enough for you.

Is there any other recourse here?

Why does making `this(...) immutable` fix things below?
Shouldn't that immutable designation mean no members of this will be modified? But that is the whole point of an initializer? Why does immutable make sense in this context at all?

My problem is a bit more elaborate and unfortunately to initialize members I need to call standard functions that have not been made pure (but should be).



struct T {
  int[] i;
}

struct S {
  int[] i;
  immutable T t;
  this(immutable T _t) {
    t = _t;
  }
}

void main() {
  auto t = immutable T();
  auto s = immutable S(t);
}

On 2013-10-16, 18:54, Daniel Davidson wrote:

> On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
>> On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels <stephan_schiffels@mac.com> wrote:
>>
>>> For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?
>>
>> In std.exception there is assumeUnique. It's basically just a cast, but
>> might be good enough for you.
>
> Is there any other recourse here?
>
> Why does making `this(...) immutable` fix things below?
> Shouldn't that immutable designation mean no members of this will be modified? But that is the whole point of an initializer? Why does immutable make sense in this context at all?

Immutable in the case of constructors means that the instance will be
created using only data implicitly castable to immutable. That way, when
construction is finished, it is safe for the type system to mark the
result as immutable.


> My problem is a bit more elaborate and unfortunately to initialize members I need to call standard functions that have not been made pure (but should be).

If you're calling functions that are not marked pure in order to create
immutable data, you will need to cast to immutable afterwards. If you
know this is safe, no problem.

It would benefit us all if you reported these functions or created a pull
request for Phobos, of course.

-- 
  Simen

On Wednesday, 16 October 2013 at 19:55:41 UTC, Simen Kjaeraas wrote:
> On 2013-10-16, 18:54, Daniel Davidson wrote:
>
>> On Thursday, 13 June 2013 at 12:29:57 UTC, Simen Kjaeraas wrote:
>>> On Thu, 13 Jun 2013 14:17:22 +0200, Stephan Schiffels <stephan_schiffels@mac.com> wrote:
>>>
>>>> For example, is there a way of instantiating an object normally (i.e. mutable), and then later "freeze" it to immutable via a simple cast or so?
>>>
>>> In std.exception there is assumeUnique. It's basically just a cast, but
>>> might be good enough for you.
>>
>> Is there any other recourse here?
>>
>> Why does making `this(...) immutable` fix things below?
>> Shouldn't that immutable designation mean no members of this will be modified? But that is the whole point of an initializer? Why does immutable make sense in this context at all?
>
> Immutable in the case of constructors means that the instance will be
> created using only data implicitly castable to immutable. That way, when
> construction is finished, it is safe for the type system to mark the
> result as immutable.
>
>
>> My problem is a bit more elaborate and unfortunately to initialize members I need to call standard functions that have not been made pure (but should be).
>
> If you're calling functions that are not marked pure in order to create
> immutable data, you will need to cast to immutable afterwards. If you
> know this is safe, no problem.
>

I'm in the learn news group for a reason. I think what you say makes sense - a cast is required. But perhaps you have more confidence that there is no problem. You and dicebot surely disagree on this practice as he sees no real reason to ever circumvent the type system.

> It would benefit us all if you reported these functions or created a pull
> request for Phobos, of course.

I reported my issue with the `chain` function to this NG and tried to start annotating items used by chain with pure to see how far the thread led. Honestly it was quickly clear that it led too far for me to follow it and someone else indicated the problem had to do with Voldermort types. If there is more I could do to "benefit us all", beyond learning how it works and what to avoid in my own code - I will be glad to try.

On Wednesday, 16 October 2013 at 20:09:51 UTC, Daniel Davidson wrote:
> You and dicebot surely disagree on this practice as he sees no real reason to ever circumvent the type system.

There are some cases were you have no other options because of language design limitations but it is something that should be done only by experienced D developers who clearly understand the impact upon the generated machine code and hidden behind the library functions. Not a casual casts in user code by any means.

On Wed, Oct 16, 2013 at 10:09:50PM +0200, Daniel Davidson wrote: [...]
> I reported my issue with the `chain` function to this NG and tried to start annotating items used by chain with pure to see how far the thread led. Honestly it was quickly clear that it led too far for me to follow it and someone else indicated the problem had to do with Voldermort types. If there is more I could do to "benefit us all", beyond learning how it works and what to avoid in my own code - I will be glad to try.

Hmm. I just did a quick-n-dirty change to Phobos, and it seems to make chain() usable with pure code. I'm not sure why the compiler didn't infer pure for it -- it should. (Or perhaps I'm missing something obvious -- I didn't run the Phobos unittest so maybe the following change breaks something.)

- In the Phobos source, edit std/range.d and look for the function `auto
  chain(Ranges...)(Ranges rs)` (around line 2022 or thereabouts), then
  the struct Result inside this function.
- Find the ctor for this struct (circa line 2074), and annotate it with
  pure.
- Now the following code compiles:

	import std.range;

	auto pureFunc() pure {
		return chain([1,2,3], [2,3,4]);
	}

	void main() {
		auto r = pureFunc();
	}

This is just a hack, of course. The compiler *should* be able to correctly infer that the ctor is pure. So the real fix is to find out why the compiler isn't doing that.


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

On Wednesday, October 16, 2013 14:10:02 H. S. Teoh wrote:
> This is just a hack, of course. The compiler *should* be able to correctly infer that the ctor is pure. So the real fix is to find out why the compiler isn't doing that.

Because it sucks at attribute inference. The inference that it does right now is very shallow:

http://d.puremagic.com/issues/show_bug.cgi?id=10329

The compiler could use a considerable improvements with regards to how much inference it's doing for templated stuff. Without it, the attribute inference for Phobos is nowhere near good enough.

- Jonathan m Davis

On Wed, Oct 16, 2013 at 02:10:02PM -0700, H. S. Teoh wrote:
> On Wed, Oct 16, 2013 at 10:09:50PM +0200, Daniel Davidson wrote: [...]
> > I reported my issue with the `chain` function to this NG and tried to start annotating items used by chain with pure to see how far the thread led. Honestly it was quickly clear that it led too far for me to follow it and someone else indicated the problem had to do with Voldermort types. If there is more I could do to "benefit us all", beyond learning how it works and what to avoid in my own code - I will be glad to try.
> 
> Hmm. I just did a quick-n-dirty change to Phobos, and it seems to make chain() usable with pure code. I'm not sure why the compiler didn't infer pure for it -- it should. (Or perhaps I'm missing something obvious -- I didn't run the Phobos unittest so maybe the following change breaks something.)
[...]

Actually, I just remembered why. It's because attribute inference only happens for the template function itself, but not for any nested structs or struct members. Arguably, the compiler should also do inference for all nested declarations in a template too.

Do you have a bugzilla ticket for this issue? I'd like to add my findings to it. Thanks!


T

-- 
Without geometry, life would be pointless. -- VS