On Mon, Jul 27, 2009 at 8:16 PM, Chad J<chadj...@__spam.is.bad__gmail.com> wrote: > Jarrett Billingsley wrote: >> On Mon, Jul 27, 2009 at 4:34 PM, Chad >> J<chadj...@__spam.is.bad__gmail.com> wrote: >> >> Nono, I don't think that's really what's being suggested. It'd work >> more like operator overloading. "opAdd" and the like aren't parsed >> any different from any other functions, and they're not represented >> differently inside the compiler; they're just functions with "magical" >> names. Similarly, opGet_foo would be a normal function in any way, >> and its name would only be significant in the case of "obj.foo", which >> *could* be rewritten as "obj.opGet_foo()" (or "obj.opSet_foo"). >> > > Op overloading is a bit different since the identifier never changes. > What you are matching is always one of opAdd, opSub, opNeg, etc. But > when matching this there are an infinite number of permutations: > opGet_foo, opGet_bar, opGet__, opGet_a, ..., opGet_aa, opGet_ab, etc. > > I'm not saying it's hard to do, just that it looks to me like it defeats > its own virtues.
I'm just saying it doesn't require any change to the grammar, is all. >> Also, if you think D can be parsed without any information from the >> semantic pass? I've got news for you.. > > Yeah, that's still not a good reason to make a bad thing worse :/ I wasn't suggesting that ;)
