On Fri, Mar 09, 2012 at 08:50:36AM -0800, Jonathan M Davis wrote: > On Friday, March 09, 2012 07:56:15 H. S. Teoh wrote: > > On Fri, Mar 09, 2012 at 03:10:00AM -0800, Jonathan M Davis wrote: > > > On Thursday, March 08, 2012 08:03:09 H. S. Teoh wrote: > > [...] > > > > TDPL, p.156, 1st two paragraphs under 5.9.1 "Pseudo Members and the > > > > > > > > @property Attribute": > > > > One syntactic problem is that function invocations so > > > > far have looked like fun(argument), whereas now we'd > > > > like to define calls that look like argument.fun() and > > > > argument.fun. The latter syntaxes are called method > > > > invocation syntax and property access syntax, > > > > respectively. We'll learn in the next chapter that > > > > they're rather easy to define for user-defined types, > > > > but T[] is a build-in type. What to do? > > > > > > > > D recognizes this as a purely syntactic issue and allows > > > > pseudo-member notation: if a.fun(b,c,d) is seen but fun > > > > is not a member of a's type, D rewrites that as fun(a, > > > > b, c, d) and tries that as well. (The opposite path is > > > > never taken, though: if you write fun(a, b, c, d) and it > > > > does not make sense, a.fun(b, c, d) is not tried.) ... [...] > > The wording is ambiguous. He said "but fun is not a member of a's > > type". Why would he say "member of a's type" if he was only > > referring to arrays? If I were to write that paragraph, and I only > > intended the rewrite to happen with arrays, I'd word it quite > > differently. It would be much clearer to say, for example, "if > > a.fun(b,c,d) is seen but fun isn't an array method, then D rewrites > > that as fun(a,b,c,d) and tries that as well." The fact that he chose > > to say "member of a's type" suggests that it was a generic feature. > > I see nothing ambiguous about it, because it _clearly_ says at the end > of the previous paragraph that it's talking about arrays. Obviously, > it's confusing some people, but I find it very weird that it is. > Regardless, if you don't think that the text is clear enough, then > Andrei would have to say what he intended. But I just don't see how > you could really think that it's talking about anything other than > arrays when it clearly says that it's talking specifically about T[], > and all of the examples use arrays. But I guess that we can just leave > it at that. [...]
The way I understood it was that he was introducing a more general concept as a solution that also applies to arrays. But anyway. There's no point arguing about this. I need to get back to working on the druntime AA implementation. :-) T -- There are four kinds of lies: lies, damn lies, and statistics.