Pure functions as initializers for immutable structures?

[Tomek Sowiński]

Dnia 18-10-2010 o 21:38:07 Steven Schveighoffer <schveiguy at yahoo.com>  
napisał(a):

> On Mon, 18 Oct 2010 15:20:39 -0400, Tomek Sowiński <just at ask.me> 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.  However with your method, it's also very possible they don't  
> provide a pure ctor.
>
> I think an immutable ctor has different restrictions.  In light of the  
> new version of pure, perhaps your idea could obviate the need for  
> immutable constructors.  In other words, a pure constructor just got a  
> *lot* easier to write, and almost all ctors should be pure.  If that's  
> the case, then many would be 'immutably pure' since they take only value  
> types.

I'd have to know what are the restrictions on immutable ctors. But I  
expect them to be very similar to restrictions that immutable(pure)  
imposes, except for mutating 'this', of course.

>> Plus, if the thing I wrote is correct, why not?
>
> Not saying it's not correct, it sounds correct to me, but I think we  
> need to verify we aren't creating too many ways to do the same thing  
> here (which may even mean immutable constructors are redundant).

Thanks for support. Well, now you can create structs either with  
constructors or with functions (especially when templatized, to infer type  
 from arguments). Immutable versions should cherish similar diversity.

>>> If that's not what you mean, can you give an example of such grief?
>>
>> Build an immutable dictionary that would hold the program's options.
>
> This particular problem should be solvable by changing the type of all  
> literals to immutable :)
>
> I think at some point, we need something like you propose -- where given  
> the properties of a function, you can implicitly convert its return  
> value to immutable.  This makes things much easier to deal with.

Yeah, *much* easier. Plus, I think what I proposed isn't much work to  
implement. But Walter would know that better.

--
Tomek