Possible way to achieve lazy loading with const objects

[Steven Schveighoffer]

On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
>> On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> > On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
>> >> "Jonathan M Davis" , dans le message (digitalmars.D:145479), a écrit  
>> :
>> >> > But since lazy initializion will _never_ work with immutable
>> >>
>> >> Never say never. One could build a clean and thread-safe way to  
>> lazily
>> >> initialize fields. Like someone said, even without mutex, if the
>> >> function to compute the variable is pure and based on immutable data,
>> >> the worst case would be to run the intializing function twice. And  
>> the
>> >> langage could include mutexes to do prevent that to happen. The fact
>> >> that immutable data could, one day, be put in ROM doesn't mean that  
>> it
>> >> has to. The close issue is like another-one said the issue of
>> >> memoization of pure methods.
>> >
>> > The very fact that an immutable variable _could_ be put into ROM  
>> negates
>> > the
>> > possibility of the semantics being such that you don't have to fully
>> > initialize an immutable variable up front.
>>
>> No it doesn't. If it's in ROM, initialize eagerly (which should cost
>> nothing, done at compile-time). If it's not, initialize lazily.
>
> That's assuming that objects can only ever be put into ROM at compile  
> time. Is
> such an assumption valid? And not just currently valid, but permanently  
> valid?

By definition ROM is read only.  How can it be created during runtime if  
it's read-only?  And if it's some hardware-based ROM, what makes it  
read/write during the constructor?

>
> Though I suppose that even if that assumption isn't valid, the compiler  
> should
> still know when it's putting something in ROM and force eager loading it  
> that
> case.
>
> However, that does introduce the whole locking issue again, since  
> immutable
> variables are implicitly shared.

Locking issues are not present when all the data is immutable.  It's why  
immutable is implicitly shared.

-Steve