www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Method invocation -- why it's not working?

reply "Comrad" <comrad.karlovich googlemail.com> writes:
   1 struct A
   2 {
   3   double[2] _x;
   4 }
   5
   6  property ref double y(ref A a) {return a._x[1];}
   7
   8 void main()
   9 {
  10   A a1;
  11   a1.y=2.;
  12 }

dmd test.d gives me:

Error: no property 'y' for type 'A'
Mar 07 2012
next sibling parent =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Thu, 08 Mar 2012 00:21:36 +0100, Comrad  
<comrad.karlovich googlemail.com> wrote:


    1 struct A
    2 {
    3   double[2] _x;
    4 }
    5
    6  property ref double y(ref A a) {return a._x[1];}
    7
    8 void main()
    9 {
   10   A a1;
   11   a1.y=2.;
   12 }

 dmd test.d gives me:

 Error: no property 'y' for type 'A'


Uniform function call syntax is not implemented. Due to what
was originally a bug, it works for arrays.
Mar 07 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/07/2012 03:21 PM, Comrad wrote:

 1 struct A
 2 {
 3 double[2] _x;
 4 }
 5
 6  property ref double y(ref A a) {return a._x[1];}
 7
 8 void main()
 9 {
 10 A a1;
 11 a1.y=2.;
 12 }

 dmd test.d gives me:

 Error: no property 'y' for type 'A'


You are testing out the new UFCS, right? Well, I really really hope that 
I will be embarrassed by saying this: That feature has been DOA! :p

So many people celebrated the feature on the D.announce newsgroup. I've 
pointed out a number of times that I couldn't get even the simplest test.

And there is a unittest that tests the feature but nope... It just 
doesn't work. :(

Ali
Mar 07 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/07/2012 03:54 PM, Ali Çehreli wrote:

 On 03/07/2012 03:21 PM, Comrad wrote:
  > 1 struct A
  > 2 {
  > 3 double[2] _x;
  > 4 }
  > 5
  > 6  property ref double y(ref A a) {return a._x[1];}
  > 7
  > 8 void main()
  > 9 {
  > 10 A a1;
  > 11 a1.y=2.;
  > 12 }
  >
  > dmd test.d gives me:
  >
  > Error: no property 'y' for type 'A'
  >
  >

 You are testing out the new UFCS, right? Well, I really really hope that
 I will be embarrassed by saying this: That feature has been DOA! :p

 So many people celebrated the feature on the D.announce newsgroup. I've
 pointed out a number of times that I couldn't get even the simplest test.

 And there is a unittest that tests the feature but nope... It just
 doesn't work. :(

 Ali


Ok, now I see how I fooled myself. Posts like the following made me 
think that UFCS has been implemented even for ints:

   http://forum.dlang.org/post/jhfpca$1bf4$1 digitalmars.com

I made a further mistake and parsed the unittest in the following change 
as using an 'int'. Obviously I was wrong: it is the string literal "1":

 
https://github.com/D-Programming-Language/dmd/commit/c268c4a2dc20aae024bce81555833b806a56f718

Ali
Mar 07 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Don't worry Ali I thought the same thing. :p
Mar 07 2012
prev sibling parent reply "Comrad" <comrad.karlovich googlemail.com> writes:
On Thursday, 8 March 2012 at 00:04:55 UTC, Ali Çehreli wrote:

 On 03/07/2012 03:54 PM, Ali Çehreli wrote:

 On 03/07/2012 03:21 PM, Comrad wrote:

 1 struct A
 2 {
 3 double[2] _x;
 4 }
 5
 6  property ref double y(ref A a) {return a._x[1];}
 7
 8 void main()
 9 {
 10 A a1;
 11 a1.y=2.;
 12 }

 dmd test.d gives me:

 Error: no property 'y' for type 'A'


 You are testing out the new UFCS, right? Well, I really really 
 hope that
 I will be embarrassed by saying this: That feature has been 
 DOA! :p

 So many people celebrated the feature on the D.announce 
 newsgroup. I've
 pointed out a number of times that I couldn't get even the 
 simplest test.

 And there is a unittest that tests the feature but nope... It 
 just
 doesn't work. :(

 Ali


 Ok, now I see how I fooled myself. Posts like the following 
 made me think that UFCS has been implemented even for ints:

   http://forum.dlang.org/post/jhfpca$1bf4$1 digitalmars.com

 I made a further mistake and parsed the unittest in the 
 following change as using an 'int'. Obviously I was wrong: it 
 is the string literal "1":


 https://github.com/D-Programming-Language/dmd/commit/c268c4a2dc20aae024bce81555833b806a56f718

 Ali


Basically, I was following Andrei's book, where this feature is 
described. It's a pity, that it's not working (except arrays 
somehow) :( - I need it!
Mar 07 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote:
[...]

 Basically, I was following Andrei's book, where this feature is
 described. It's a pity, that it's not working (except arrays somehow)
 :( - I need it!


Yeah there are some features in the book that aren't completely
implemented yet. They are being looked into with high priority.


T

-- 
Acid falls with the rain; with love comes the pain.
Mar 07 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote:
 [...]
 

 Basically, I was following Andrei's book, where this feature is
 described. It's a pity, that it's not working (except arrays somehow)
 
 :( - I need it!


 
 Yeah there are some features in the book that aren't completely
 implemented yet. They are being looked into with high priority.


True. But I would point out that TDPL never actually says that it works with 
all types. It only shows it with arrays. Now, it's not entirely clear on 
whether it's supposed to work with all types, but it definitely doesn't say 
that it does. It wouldn't surprise me at all if Andrei wrote it with the 
intention that it was only supposed to work with arrays but wasn't clear 
enough in his description.

Still, there are definitely a lot of people who want it to work with all types, 
so it's likely that it will be expanded to work with more types. Whether it 
will ever work with _all_ types is somewhat in question due to ambiguity 
issues involving structs and classes (e.g. when a member function and a free 
function using UFCS would conflict). But there's a decent chance that that will 
be resolved and UFCS will end up working for all types. Until then though, all 
it works with is arrays.

- Jonathan M Davis
Mar 07 2012
parent reply "Comrad" <comrad.karlovich googlemail.com> writes:
On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote:

 On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote:
 [...]
 

 Basically, I was following Andrei's book, where this feature 
 is
 described. It's a pity, that it's not working (except arrays 
 somehow)
 
 :( - I need it!


 
 Yeah there are some features in the book that aren't completely
 implemented yet. They are being looked into with high priority.


 True. But I would point out that TDPL never actually says that 
 it works with
 all types. It only shows it with arrays. Now, it's not entirely 
 clear on
 whether it's supposed to work with all types, but it definitely 
 doesn't say
 that it does. It wouldn't surprise me at all if Andrei wrote it 
 with the
 intention that it was only supposed to work with arrays but 
 wasn't clear
 enough in his description.


It's not correct. In TDPL it is clearly stated, that this is a 
general feature
of the language.



 Still, there are definitely a lot of people who want it to work 
 with all types,
 so it's likely that it will be expanded to work with more 
 types. Whether it
 will ever work with _all_ types is somewhat in question due to 
 ambiguity
 issues involving structs and classes (e.g. when a member 
 function and a free
 function using UFCS would conflict). But there's a decent 
 chance that that will
 be resolved and UFCS will end up working for all types. Until 
 then though, all
 it works with is arrays.

 - Jonathan M Davis


Anyway, for structures this feature is really needed.
Mar 07 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 08:37:38 Comrad wrote:

 On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote:

 On Wednesday, March 07, 2012 22:40:02 H. S. Teoh wrote:

 On Thu, Mar 08, 2012 at 07:32:18AM +0100, Comrad wrote:
 [...]
 

 Basically, I was following Andrei's book, where this feature
 is
 described. It's a pity, that it's not working (except arrays
 somehow)
 
 :( - I need it!


 
 Yeah there are some features in the book that aren't completely
 implemented yet. They are being looked into with high priority.


 
 True. But I would point out that TDPL never actually says that
 it works with
 all types. It only shows it with arrays. Now, it's not entirely
 clear on
 whether it's supposed to work with all types, but it definitely
 doesn't say
 that it does. It wouldn't surprise me at all if Andrei wrote it
 with the
 intention that it was only supposed to work with arrays but
 wasn't clear
 enough in his description.


 
 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.


 Still, there are definitely a lot of people who want it to work
 with all types,
 so it's likely that it will be expanded to work with more
 types. Whether it
 will ever work with _all_ types is somewhat in question due to
 ambiguity
 issues involving structs and classes (e.g. when a member
 function and a free
 function using UFCS would conflict). But there's a decent
 chance that that will
 be resolved and UFCS will end up working for all types. Until
 then though, all
 it works with is arrays.
 
 - Jonathan M Davis


 
 Anyway, for structures this feature is really needed.


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
Mar 07 2012
parent reply "Kapps" <opantm2+spam gmail.com> writes:
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
Mar 08 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 08 2012
prev sibling parent "Comrad" <comrad.karlovich googlemail.com> writes:
On Thursday, 8 March 2012 at 08:19:02 UTC, 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/b7742f7a733ff73d364c6ed54af70d875d7e911b
 :D


Great news!
Mar 09 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 08 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 09 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Yeah I understood it as a general concept as well. Probably many
people did. Why doesn't Andrei chime in?
Mar 09 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 09 2012
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/9/12, Timon Gehr <timon.gehr gmx.ch> wrote:

 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.


Ah poo. This is like East Berlin in here. :P
Mar 10 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Mar 09 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 09, 2012 19:13:02 Andrej Mitrovic wrote:

 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?




I don't think that Andrei even pays attention to D.learn. Certainly, if he's 
ever posted in it, it's been quite a while.


 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.


Arrays have been supported with such syntax for ages. UFCS has not, and it has 
been a subject of debate whether it should be. It certainly was not generally 
accepted and expected when TDPL was released that we would get UFCS. And if he 
_were_ talking about UFCS, then he'd be talking about stuff like 5.max(7), not 
just arrays. He also likely use the term Universal Function Call Syntax. But 
he doesn't do that. Rather, he specifically talks about arrays, and all of the 
examples use arrays.

- Jonathan M Davis
Mar 09 2012