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.) ... > > > > > > In the second paragraph, it seems that it should apply to all types, > > > since Andrei says "but fun is not a member of a's type". If 'a' were to > > > be restricted only to arrays, why did he say "a's type"? Why didn't he > > > say "but fun is not an array method" or something along those lines? > > > Granted, the context is speaking about arrays, but the wording "a's > > > type" seems to be intentionally generic. > > > > Yeah. That says _nothing_ about UFCS working with types other than > > arrays. It clearly states that the discussion of how to add them to > > user-defined types is discussed in the next chapter (which is on > > classes and includes defining member functions which are methods or > > properties without any UFCS stuff with free functions). It then > > specifically asks the question about what to do about arrays and then > > goes into an explanation about how you can define free functions which > > can use member invocation syntax and property syntax. _Nowhere_ does > > it discuss adding free functions which work for other built-in types > > (such as int or float), and _nowhere_ does it discuss using free > > functions to add member functions to classes or structs via UFCS. > > Um... did you even read the second quoted paragraph? Andrei did not say > 'a' is specifically an array. He said it's a type for which fun is not a > member function. It's entirely reasonable to understand Andrei's wording > as meaning that the rewrite from a.fun(b,c,d) --> fun(a, b, c, d) is > intended to be generically across any type of 'a'. It's an exposition of > the form "we can make X work for user-defined types, but X doesn't work > for arrays because we can't add members to arrays. But don't worry, D > also has feature Y, so in the case of arrays, using feature Y solves the > problem." > > As to whether this was his actual intention, it's not for me to say. But > do not be surprised if many people interpret that paragraph to mean that > UFCS works across all types. > > > I think that it's crystal clear that it's _not_ talking about UFCS but > > rather simply using member invocation syntax with arrays. > > 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. - Jonathan M Davis