View mode: basic / threaded / horizontal-split · Log in · Help
December 06, 2010
const(Object)ref is here!
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/
December 06, 2010
Re: const(Object)ref is here!
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/
>
>
December 06, 2010
Re: const(Object)ref is here!
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
December 06, 2010
Re: const(Object)ref is here!
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/
December 06, 2010
Re: const(Object)ref is here!
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
December 06, 2010
Re: const(Object)ref is here!
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
December 06, 2010
Re: const(Object)ref is here!
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
December 06, 2010
Re: const(Object)ref is here!
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
December 06, 2010
Re: const(Object)ref is here!
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).
December 06, 2010
Re: const(Object)ref is here!
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home