QtD is suspended

[Michel Fortin]

On 2010-09-17 11:14:21 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 9/17/10 9:18 CDT, Michel Fortin wrote:
>> On 2010-09-17 04:15:31 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>> 
>>> On a funny note, we figured that for a number of reasons it would help
>>> to allow C++-style constructors that offer access to the source; it
>>> just turns out some idioms need to modify the source as well as the
>>> destination.
>>> 
>>> One obvious example is the built-in hashtable that is not shared
>>> properly when it's null. Making the copy constructor spring the
>>> hashtable to life would make it more uniform in behavior.
>> 
>> At the basic level I feel uneasy with this whole idea of modifying the
>> source while copying. It means that you can't copy the source if it is
>> const. Do you really want to make const containers uncopyable?
> 
> Again, the scenario is motivated by this:
> 
> void main()
> {
>      int[int] hash;
>      fun(hash);
>      assert(!(42 in hash));
>      hash[0] = 10;
>      fun(hash);
>      assert(42 in hash);
> }
> 
> void fun(int[int] hash)
> {
>      hash[42] = 42;
> }
> 
> Walter's idea was as follows. If the hash's copy constructor has access 
> to the source, then that constructor could lazily initialize the 
> pointer internally shared by the existing instance (the one in main()) 
> and the one being created (the one passed to fun()). Then, the program 
> would behave more predictably and also stay efficient - lazy 
> initialization for the win.

I understand the intent quite well. I'm talking about what happens if 
the source is const? As in:

	struct A {
		int[int] hash;

		int[int] fun() {
			return hash; // hash can be altered, can copy
		}

		const const(int[int]) fun() {
			return hash; // here hash is const, what happens?
		}
	}

With the second accessor the hash is const, so how can you copy it 
anywhere if copying requires altering the original? Should it be an 
error? Should the copy be detached when the source is const, breaking 
reference semantics? Or should we add logical-const (in addition to 
C++-style constructors)?

Now that I think of it, you don't need a fancy struct to make this 
problem appear, you just need two layers of functions:

	void fun(const(int[int]) hash) {
		fun(hash); // calling ourself, how can we copy hash?
	}

Although in this case we could probably assert() that hash is already 
initialized.

In my mind it's simpler to just explain the notion that an 
uninitialized hash is null and detached from anything else until 
initialized. Objects works like this (minus the implicit initialization 
part), so it shouldn't be too hard to understand. Better have pragmatic 
semantics that work rather than idealistic semantics that fail at a 
number of cases.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/