equivariant functions

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Thu, Oct 16, 2008 at 12:46 AM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>>
>> "Bill Baxter"wrote
>>> On Wed, Oct 15, 2008 at 10:13 AM, Steven Schveighoffer
>>>> I'm not a fan of complexity where it is not required.
>>>>
>>>> You have outlined pretty much exactly the only use cases for this
>>>> feature.
>>>> So why do you want to continually write large typedefs that are 
>>>> identical
>>>> in
>>>> front of all your functions, when you can do so with a succinct syntax?
>>>
>>> Think of it this way: right now to create variations on const you have
>>> to declare the method three times.  This would reduce that to one
>>> short preamble + one declaration.
>>
>> An example class with 10 accessors (forget about the implementations):
>>
>> Your way:
>>
>> class Owner
>> {
>>   typedef {  Const : const }
>>   Const(A) a() Const {...}
>>
>>   [...]
>>
>>   // written by another author who prefers a different identifier for 
>> Const
>>   typedef {  Konst : const }
>>   Konst(J) j() Konst {...}
>> }
>>
>> My way:
>>
>> class Owner
>> {
>>   inout(A) a() inout {...}
>>
>>   [...]
>> }
>>
>> It might be just me, but my way seems cleaner and easier to implement.
>
> Good example.
> Definitely seems easier to implement.  And agreed that for common
> cases it has less clutter.
>
> I could suggest making some class-scoped version of the typedef{Const
> : const} thing, but at that point it would just become a different
> name for your "inout", and would have the disadvantage of different
> people giving different names to something that will be used in just
> about every class.
>
> Hmmm, looking at this:
>
> class Owner
> {
>  const?(A) a() const?{...}
>  const?(B) b() const?{...}
>  const?(C) c() const?{...}
>  const?(D) d() const?{...}
>  const?(E) e() const?{...}
>  const?(F) f() const?{...}
>  const?(G) g() const?{...}
>  const?(H) h() const?{...}
>  const?(I) i() const?{...}
>  const?(J) j() const?{...}
> }
>
> makes me think if we go with that syntax, Andrei is sooner or later
> going to complain about his D code asking him too many questions.  :-)
> Eh, I guess he can edit the emacs mode to display const? as
> smiley-faces or something.  :-) :-)

lol!

or should I say lol?

I'm pretty sure this isn't taken:

const!(x)

and his emacs module could translate it to:

const <<x>>

(Yes, I have no idea how to type those weird characters ;)

>
>>> Here's something that comes up -- iterators in C++ usually end up
>>> needing to come in const and non-const flavors.  The "head" of both is
>>> mutable, but the "tail" is const on the const flavor.  How do you
>>> write this pair of functions as one?:
>>
>> You can't cast an iterator to 'head const' (another nagging problem, but 
>> a
>> separate one), so the only viable option is templates.
>
> I don't understand this comment.  Why would you need to cast iterators
> to "head const"?  I think head const is not supported by the current
> const design at all -- via casting or otherwise.

Damn!  I always do that!

swap head const with tail const, sorry ;)

-Steve