On Thursday, 8 March 2012 at 07:53:02 UTC, Jonathan M Davis wrote:
> It would be nice, but I honestly don't understand the people who think that
> the lack of it is crippling. It's just one of those nice-to-have features.
> Most languages don't have anything of the sort.
>
> - Jonathan M Davis

Speaking of UFCS...
https://github.com/D-Programming-Language/dmd/commit/b7742f7a733ff73d364c6ed54af70d875d7e911b
:D

On Thursday, March 08, 2012 09:19:01 Kapps wrote:
> On Thursday, 8 March 2012 at 07:53:02 UTC, Jonathan M Davis wrote:
> > It would be nice, but I honestly don't understand the people
> > who think that
> > the lack of it is crippling. It's just one of those
> > nice-to-have features.
> > Most languages don't have anything of the sort.
> > 
> > - Jonathan M Davis
> 
> Speaking of UFCS...
> https://github.com/D-Programming-Language/dmd/commit/b7742f7a733ff73d364c6ed
> 54af70d875d7e911b
> :D

Yes. Kenji Hara is working on getting at least some portion if it into the compiler. I'm not quite sure what he is and isn't currently implementing for it though. Regardless, it looks like the amount of stuff that works with UFCS will be increasing with the next release.

- Jonathan M Davis

On Wed, Mar 07, 2012 at 11:50:57PM -0800, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 08:37:38 Comrad wrote:
> > On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote:
[...]
> > It's not correct. In TDPL it is clearly stated, that this is a general feature of the language.
> 
> Then please give me a page number. Last time I looked it over, I saw _nothing_ which said that it worked on types in general, and _all_ examples used arrays.

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.


[...]
> It would be nice, but I honestly don't understand the people who think that the lack of it is crippling. It's just one of those nice-to-have features.  Most languages don't have anything of the sort.
[...]

It *is* crippling if you're trying to write generic code, like Andrei was doing with find() in the TDPL page I quoted above. You just invented a new algorithm that abstracts away certain primitives that you'd like to generalize across all types. So now you merrily go along and implement primitive1, primitive2, etc., in all your struct's and objects. But then you run into built-in types, and discover that UFCS doesn't work for that type. I'd say that *is* rather crippling. You'd have to special-case all relevant primitive types, which defeats the purpose of generic code (imagine if find() and family had to be special cased for arrays -- there'd be a lot of code bloat in std.algorithm).


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

On Thursday, March 08, 2012 08:03:09 H. S. Teoh wrote:
> On Wed, Mar 07, 2012 at 11:50:57PM -0800, Jonathan M Davis wrote:
> > On Thursday, March 08, 2012 08:37:38 Comrad wrote:
> > > On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote:
> [...]
> 
> > > It's not correct. In TDPL it is clearly stated, that this is a general feature of the language.
> > 
> > Then please give me a page number. Last time I looked it over, I saw _nothing_ which said that it worked on types in general, and _all_ examples used arrays.
> 
> 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.

I think that it's crystal clear that it's _not_ talking about UFCS but rather simply using member invocation syntax with arrays.

So, while we may very well end up with UFCS in the language on some level (if not completely implemented in all its glory), TDPL does _not_ discuss UFCS. It _only_ discusses member invocation syntax on arrays. So, if UFCS were to never happen, it wouldn't contradict TDPL.

- Jonathan M Davis

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.


> So, while we may very well end up with UFCS in the language on some level (if not completely implemented in all its glory), TDPL does _not_ discuss UFCS. It _only_ discusses member invocation syntax on arrays. So, if UFCS were to never happen, it wouldn't contradict TDPL.
[...]

I'm not going to pick a fight with you, but I'm just saying that, as it stands, the wording suggests that the rewrite from a.fun(b,c,d) to fun(a,b,c,d) happens across the board. Andrei did not make it clear that only arrays were intended. So even if he didn't *intend* for this rewrite to happen for all types, a reader who didn't know any better would assume that it did work across all types, because of the genericity of the wording.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater learning.

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

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.

Yeah I understood it as a general concept as well. Probably many people did. Why doesn't Andrei chime in?

On 3/9/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Yeah I understood it as a general concept as well. Probably many people did. Why doesn't Andrei chime in?
>

Btw, we all know how much Andrei loves generics so why the heck would he care about arrays so much to only give them special properties? I'm almost 100% sure he meant UFCS to be available for all types. And if not, I bet he wouldn't second-guess this feature. IOW I think Jonathan is just being pedantic about wording.

On 03/09/2012 07:08 PM, Andrej Mitrovic wrote:
> Yeah I understood it as a general concept as well. Probably many
> people did. Why doesn't Andrei chime in?

I think he does not read the D.learn newsgroup.