On Wed, 16 Dec 2009 19:05:09 -0500, Michel Fortin
<[email protected]> wrote:
On 2009-12-16 16:46:14 -0500, Jason House <[email protected]>
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;
}
This can never work. a const?(Object) is const during the function
execution, and cannot be assigned to.
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.
This doesn't have the same utility as vconst, since you can't apply Object
to other types like you can constancy.
Plus you can already do this with a template and have a virtual version of
the func:
T func(T)(T o) if(T : Object) {func_virt(o); return o; }
protected void func_virt(Object o) {writeln(o.toString());}
-Steve
