On Wed, 16 Dec 2009 07:20:11 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 15 Dec 2009 23:04:38 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Michel Fortin wrote:
On 2009-12-15 22:41:19 -0500, "Steven Schveighoffer"
<schvei...@yahoo.com> said:
2. the choice of inout is not my first choice, I'd prefer a new
keyword. The inout compromise was meant to subvert the "we already
have too many keywords" argument (it was Janice's idea). If there
are no objections, I prefer what the DIP proposed, vconst. All I'm
saying is, reusing inout is *not* a very important part of the
proposal.
Seconded. In fact, we could just remove inout from the keyword list
if we care about not augmenting the number of keywords.
Regardless of legacy, I personally find "inout" more suggestive - the
qualifier goes from input to output. vconst doesn't quite tell me
anything. I don't even know what "v" stands for.
"virtual" const :)
My original proposal called the technique "Scoped" const, which I think
is pretty accurate, since the data is const only for the scope of the
function. perhaps sconst?
or aconst for "any" const?
In any case inout is fine by me if that's what gits 'er done. The only
problem I see with inout is that it has legacy issues.
-Steve
I suggested sameconst/shareconst. It is longer but I believe it's more
descriptive, as it describes that two (or more) types share the same
"constness modifier".
sameconst(T)[] find(sameconst(T)[] haystack, T needle) { ... } // my
solution to your inout(T)[] problem
It could be shortened to same(T) but people didn't like it either.
I think it should be bikeshed(T)! :)
