On Thursday, 14 June 2012 at 13:21:34 UTC, Jacob Carlborg wrote:
> If you want that and have it immutable you need to make a deep copy of the passed in object to be safe. You could use const instead and also making the argument const. If an argument is const you can pass both mutable and immutable values, and const of course.
Thanks, I'll try that.

On Thursday, 14 June 2012 at 13:31:01 UTC, Roman D. Boiko wrote:
> On Thursday, 14 June 2012 at 13:21:34 UTC, Jacob Carlborg wrote:
>> If you want that and have it immutable you need to make a deep copy of the passed in object to be safe. You could use const instead and also making the argument const. If an argument is const you can pass both mutable and immutable values, and const of course.
> Thanks, I'll try that.
But then I will have problems sharing such data structures with different threads, correct?

On Thursday, 14 June 2012 at 13:33:43 UTC, Roman D. Boiko wrote:
> On Thursday, 14 June 2012 at 13:31:01 UTC, Roman D. Boiko wrote:
>> On Thursday, 14 June 2012 at 13:21:34 UTC, Jacob Carlborg wrote:
>>> If you want that and have it immutable you need to make a deep copy of the passed in object to be safe. You could use const instead and also making the argument const. If an argument is const you can pass both mutable and immutable values, and const of course.
>> Thanks, I'll try that.
> But then I will have problems sharing such data structures with different threads, correct?
Convenience of usage would be less important than compiler guarantees, so it looks like I have to stick to immutable, not const.

On 2012-06-14 15:33, Roman D. Boiko wrote:

> But then I will have problems sharing such data structures with
> different threads, correct?

Yes. At least the compiler can't guarantee anything.

-- 
/Jacob Carlborg

On Thursday, June 14, 2012 15:53:45 Roman D. Boiko wrote:
> On Thursday, 14 June 2012 at 13:33:43 UTC, Roman D. Boiko wrote:
> > On Thursday, 14 June 2012 at 13:31:01 UTC, Roman D. Boiko wrote:
> >> On Thursday, 14 June 2012 at 13:21:34 UTC, Jacob Carlborg
> >> 
> >> wrote:
> >>> If you want that and have it immutable you need to make a deep copy of the passed in object to be safe. You could use const instead and also making the argument const. If an argument is const you can pass both mutable and immutable values, and const of course.
> >> 
> >> Thanks, I'll try that.
> > 
> > But then I will have problems sharing such data structures with different threads, correct?
> 
> Convenience of usage would be less important than compiler guarantees, so it looks like I have to stick to immutable, not const.

Well, if you break the compiler guarantees, then your program will not work properly. const and immutable need to be used in such a way that you do not break the compiler's guarantees. If you're having to cast with const or immutable, then you're probably doing something wrong.

- Jonathan M Davis

Am 14.06.2012 15:26, schrieb Roman D. Boiko:
> But now, with everything immutable, I had to comment out several
> test cases. I cannot pass an immutable struct allocated on stack,
> into a method by reference, and then store a pointer to it,

thats sounds very evil - with or without immutable
how should that work anyway?

> because compiler says it is not an l-value. Should I allocate it
> on heap? Or get rid of functions taking parameter by ref, and use
> only those which take a pointer?

i would use the heap and ref - else you need to copy, the pointer would also not work if your struct is still in the stack - or does the stack live long enough?

On Thursday, 14 June 2012 at 15:21:53 UTC, dennis luehring wrote:
> Am 14.06.2012 15:26, schrieb Roman D. Boiko:
>> But now, with everything immutable, I had to comment out several
>> test cases. I cannot pass an immutable struct allocated on stack,
>> into a method by reference, and then store a pointer to it,
>
> thats sounds very evil - with or without immutable
> how should that work anyway?
>
>> because compiler says it is not an l-value. Should I allocate it
>> on heap? Or get rid of functions taking parameter by ref, and use
>> only those which take a pointer?
>
> i would use the heap and ref - else you need to copy, the pointer would also not work if your struct is still in the stack - or does the stack live long enough?

I agree, just looking how to accomplish my goals. I decided to get rid of casting, and will store everything on heap. I don't know how to put a variable of type float to the heap, and thought that it would be nice to allow the user to pass anything inside, but copy when that is not an l-value.

I posted another question: http://forum.dlang.org/thread/nsishethfwgxygsmzjwi@forum.dlang.org

On Thursday, June 14, 2012 17:32:03 Roman D. Boiko wrote:
> I don't know how to put a variable of type float to the heap

auto f = new float;
*f = 2.1;

- Jonathan M Davis

On Thursday, 14 June 2012 at 16:24:43 UTC, Jonathan M Davis wrote:
> On Thursday, June 14, 2012 17:32:03 Roman D. Boiko wrote:
>> I don't know how to put a variable of type float to the heap
>
> auto f = new float;
> *f = 2.1;
>
> - Jonathan M Davis

Except for immutable I would need to cast when passing into a function. That's dangerous, given that *f might be changed later. But looks like Timon's suggestion from my other question should work.

immutable a = [2.1].ptr;

On Thursday, June 14, 2012 18:32:18 Roman D. Boiko wrote:
> On Thursday, 14 June 2012 at 16:24:43 UTC, Jonathan M Davis wrote:
> > On Thursday, June 14, 2012 17:32:03 Roman D. Boiko wrote:
> >> I don't know how to put a variable of type float to the heap
> > 
> > auto f = new float;
> > *f = 2.1;
> > 
> > - Jonathan M Davis
> 
> Except for immutable I would need to cast when passing into a function. That's dangerous, given that *f might be changed later. But looks like Timon's suggestion from my other question should work.
> 
> immutable a = [2.1].ptr;

Yeah. That'll probably work. I wish that you could do

auto f = new float(2.1);

and therefore

auto f = new immutable(float)(2.1);

but you can't. You _can_ do

auto f = new float;
*f = 2.1;
immutable g = cast(immutable float*)f;

and that's safe, because there are no other references to the data, but it's certainly not all that desirable. The slightly more idomatic way to do it is

auto f = new float;
*f = 2.1;
immutable g = std.exception.assumeUnique(f);

But it's doing the same thing and you have to worry about the same safety issues.

However, if Timon's suggestion works, that's great.

- Jonathan M Davis