auto ref

[Michel Fortin]

On 2009-12-16 16:46:14 -0500, Jason House <jason.james.house at gmail.com> said:

> Walter Bright Wrote:
> 
>> Jason House wrote:
>>> KennyTM~ Wrote:
>>> 
>>>> auto const?
>>> 
>>> I was wondering the same thing.
>> 
>> The const transport thing is, unfortunately, a very different problem.
> 
> Of course, but it may still go through bikeshed issues. This morning I 
> read about inout, return, vconst, aconst, sameconst, autoconst, auto 
> const, and bikeshed. At least one of those was in jest :) auto const 
> isn't that bad, and you obviously liked auto ref...

Since this is just a special kind of const, it could be called "const^" 
(const or a derived constness):

	const?(Object) func(const?(Object) o) {
		return o;
	}

The interesting thing about it, beside not taking a keyword, is that it 
can scale in the future if we need to add many distinct constness to 
the same function signature:

	const?(Object) func(const?(Object) o, const?2(Object) o2, out 
const?2(Object) o3) {
		o3 = o2;
		return o;
	}

Not that you'd need that often, but if it does becomes necessary in the 
future we'll still have some options.

Furthermore, the concept could be extended to any type. This could be 
useful with class hierarchies:

	Object? func(Object? o) {
		writeln(o.toString());
		return o;
	}

	MyObject o = func(new MyObject);

Here, "Object?" means Object or a derived type.

Yeah, that breaks the proposed syntax for nullable types... just too 
bad. If that's really a problem we could use ^ instead.


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