Method invocation -- why it's not working?

[Jonathan M Davis]

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