After a recent discussion on this list about tail-const class references, it became rather clear that someone interested would have to implement the thing if we were to have it. So I did it. See enhancement request 5325 for an explanation and a patch.
<http://d.puremagic.com/issues/show_bug.cgi?id=5325>

Let's hope Walter likes my patch.

In the tail-const thread, I proposed the challenge of making this code work when an array of const object is passed as an argument:

	T[] giveMeASortedArray(alias Predicate, T)(T[] t) {
		// creating new array of the same length but with assignable elements
		auto copy = new Unqual!(typeof(t[0]))[t.length];
		foreach (index, value; t)
			copy[index] = value;
	
		// sorting the copy
		sort!(Predicate)(copy);
		return copy;
	}

Well, with the patch I made it now works!... irrespective of the type attribute (const,immutable,shared,inout). The only modification required to Phobos is to make to!string() compile when passed a const(Object) because somehow 'sort' requires that.

Here is how the function is invoked:

	void main() {
		int*[] a = giveMeASortedArray!("a < b")(new int*[12]);
		Object[] b = giveMeASortedArray!("a < b")(new Object[12]);
	
		const(int*)[] c = giveMeASortedArray!("a < b")(new const(int*)[12]);
		const(Object)[] d = giveMeASortedArray!("cast(void*)a < cast(void*)b")(new const(Object)[12]);
	}

See the strange predicate for the const(Object) version? That's because opCmp() in Object doesn't work with const.

Two minor modifications are required in Phobos to make the above compile. First, to!string(const(Object)) needs an implementation because somehow 'sort' requires it. Also template std.traits.isMutable needed an adjustment so that swap()'s template constrains are satisfied.


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

That was fast. 0o

:)

On 12/6/10, Michel Fortin <michel.fortin@michelf.com> wrote:
> After a recent discussion on this list about tail-const class references, it became rather clear that someone interested would have to implement the thing if we were to have it. So I did it. See enhancement request 5325 for an explanation and a patch. <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
>
> Let's hope Walter likes my patch.
>
> In the tail-const thread, I proposed the challenge of making this code work when an array of const object is passed as an argument:
>
> 	T[] giveMeASortedArray(alias Predicate, T)(T[] t) {
> 		// creating new array of the same length but with assignable elements
> 		auto copy = new Unqual!(typeof(t[0]))[t.length];
> 		foreach (index, value; t)
> 			copy[index] = value;
> 
> 		// sorting the copy
> 		sort!(Predicate)(copy);
> 		return copy;
> 	}
>
> Well, with the patch I made it now works!... irrespective of the type
> attribute (const,immutable,shared,inout). The only modification
> required to Phobos is to make to!string() compile when passed a
> const(Object) because somehow 'sort' requires that.
>
> Here is how the function is invoked:
>
> 	void main() {
> 		int*[] a = giveMeASortedArray!("a < b")(new int*[12]);
> 		Object[] b = giveMeASortedArray!("a < b")(new Object[12]);
> 
> 		const(int*)[] c = giveMeASortedArray!("a < b")(new const(int*)[12]);
> 		const(Object)[] d = giveMeASortedArray!("cast(void*)a <
> cast(void*)b")(new const(Object)[12]);
> 	}
>
> See the strange predicate for the const(Object) version? That's because
> opCmp() in Object doesn't work with const.
>
> Two minor modifications are required in Phobos to make the above
> compile. First, to!string(const(Object)) needs an implementation
> because somehow 'sort' requires it. Also template std.traits.isMutable
> needed an adjustment so that swap()'s template constrains are satisfied.
>
>
> --
> Michel Fortin
> michel.fortin@michelf.com
> http://michelf.com/
>
>

First, I have to say that it is wonderful that someone is taking a serious look at this area again, and even better, you have come up with a compiler patch to make it happen!

Some questions (assuming your patch or something like it gets into dmd):

Does this mean that I would be able to write this:
immutable(Foo)ref foo; // create a reference
foo = new immutable(Foo)(); // re-bind it (not sure about "new" syntax for immutables)

Are there any other show-stopping syntax issues that are holding up widespread adoption/rollout of const-correctness?

What do Walter and Andrei think?

Does anyone know what the plan is for rolling const-correctness thoughout druntime and phobos (and shared/immutable in std.concurrency)? Having to do casting all the time is a real drag. I for one would be happy to help if help is needed.


On 06/12/10 11:21, Michel Fortin wrote:
> After a recent discussion on this list about tail-const class references, it became rather clear that someone interested would have to implement the thing if we were to have it. So I did it. See enhancement request 5325 for an explanation and a patch.
> <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
>
> Let's hope Walter likes my patch.
>
> In the tail-const thread, I proposed the challenge of making this code work when an array of const object is passed as an argument:
>
>     T[] giveMeASortedArray(alias Predicate, T)(T[] t) {
>         // creating new array of the same length but with assignable elements
>         auto copy = new Unqual!(typeof(t[0]))[t.length];
>         foreach (index, value; t)
>             copy[index] = value;
>
>         // sorting the copy
>         sort!(Predicate)(copy);
>         return copy;
>     }
>
> Well, with the patch I made it now works!... irrespective of the type attribute (const,immutable,shared,inout). The only modification required to Phobos is to make to!string() compile when passed a const(Object) because somehow 'sort' requires that.
>
> Here is how the function is invoked:
>
>     void main() {
>         int*[] a = giveMeASortedArray!("a < b")(new int*[12]);
>         Object[] b = giveMeASortedArray!("a < b")(new Object[12]);
>
>         const(int*)[] c = giveMeASortedArray!("a < b")(new const(int*)[12]);
>         const(Object)[] d = giveMeASortedArray!("cast(void*)a < cast(void*)b")(new const(Object)[12]);
>     }
>
> See the strange predicate for the const(Object) version? That's because opCmp() in Object doesn't work with const.
>
> Two minor modifications are required in Phobos to make the above compile. First, to!string(const(Object)) needs an implementation because somehow 'sort' requires it. Also template std.traits.isMutable needed an adjustment so that swap()'s template constrains are satisfied.
>
>


-- 
Graham St Jack

On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin <michel.fortin@michelf.com> wrote:

> <http://d.puremagic.com/issues/show_bug.cgi?id=5325>

Great!

> See the strange predicate for the const(Object) version? That's because opCmp() in Object doesn't work with const.

For the same reason opEquals acting funny with const?

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sunday 05 December 2010 23:59:58 so wrote:
> On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
> 
> <michel.fortin@michelf.com> wrote:
> > <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
> 
> Great!
> 
> > See the strange predicate for the const(Object) version? That's because
> > opCmp() in Object doesn't work with const.
> 
> For the same reason opEquals acting funny with const?

Neither are marked as const on Object itself, and that needs to happen for Object to be const correct. toHash() and toString() (or writeFrom() or whatever it's going to become) have the same problem. None of them are const in Object.

- Jonathan M Davis

On Mon, 6 Dec 2010 00:31:41 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> toString() (or writeFrom() or whatever it's going to become)

guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

spir <denis.spir@gmail.com> wrote:

> On Mon, 6 Dec 2010 00:31:41 -0800
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> toString() (or writeFrom() or whatever
>> it's going to become)
>
> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it

This reminded me of INTERCAL's WRITE IN and READ OUT.


-- 
Simen

On Mon, 06 Dec 2010 04:44:07 -0500, spir <denis.spir@gmail.com> wrote:

> On Mon, 6 Dec 2010 00:31:41 -0800
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> toString() (or writeFrom() or whatever
>> it's going to become)
>
> guess it was writeTo() ;-) but "writeFrom" is nice as well, we should find some useful use for it

It was proposed as writeTo, but I'm not opposed to a different name.

BTW, the proposal does properly mark writeTo as const.

-Steve

Jonathan M Davis Wrote:

> On Sunday 05 December 2010 23:59:58 so wrote:
> > On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
> > 
> > <michel.fortin@michelf.com> wrote:
> > > <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
> > 
> > Great!
> > 
> > > See the strange predicate for the const(Object) version? That's because
> > > opCmp() in Object doesn't work with const.
> > 
> > For the same reason opEquals acting funny with const?
> 
> Neither are marked as const on Object itself, and that needs to happen for Object to be const correct. toHash() and toString() (or writeFrom() or whatever it's going to become) have the same problem. None of them are const in Object.
> 
> - Jonathan M Davis

If object did that, things deriving from Object could not be lazy or memoize. It occurs to me that things deriving from object should be able to use const-correct functions and still compile. I don't have a D compiler handy or I'd see how well dmd handles that. I'd expect changing an input argument from T to const(T) should work since it's expanding the range of valid inputs. Similarly, the method itself should be able to become const since that too is expanding the valid input (to the implicit first argument).

Jason House Wrote:

> Jonathan M Davis Wrote:
> 
> > On Sunday 05 December 2010 23:59:58 so wrote:
> > > On Mon, 06 Dec 2010 02:51:32 +0200, Michel Fortin
> > > 
> > > <michel.fortin@michelf.com> wrote:
> > > > <http://d.puremagic.com/issues/show_bug.cgi?id=5325>
> > > 
> > > Great!
> > > 
> > > > See the strange predicate for the const(Object) version? That's because
> > > > opCmp() in Object doesn't work with const.
> > > 
> > > For the same reason opEquals acting funny with const?
> > 
> > Neither are marked as const on Object itself, and that needs to happen for Object to be const correct. toHash() and toString() (or writeFrom() or whatever it's going to become) have the same problem. None of them are const in Object.
> > 
> > - Jonathan M Davis
> 
> If object did that, things deriving from Object could not be lazy or memoize. It occurs to me that things deriving from object should be able to use const-correct functions and still compile. I don't have a D compiler handy or I'd see how well dmd handles that. I'd expect changing an input argument from T to const(T) should work since it's expanding the range of valid inputs. Similarly, the method itself should be able to become const since that too is expanding the valid input (to the implicit first argument).

I should have added: if anyone tests making derived object's methods const-correct and it fails to compile, then it should be filed into bugzilla.