equivariant functions

Bill Baxter wbaxter at gmail.com
Wed Oct 15 12:00:44 PDT 2008


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.  :-) :-)

>> 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.

--bb



More information about the Digitalmars-d mailing list