www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UFCS and constructors

reply "monarch_dodra" <monarchdodra gmail.com> writes:
Coming back from learn here. There was an example where somebody 
"accidentally" called a constructor via UFCS. I am kind of 
surprised that it worked. I thought UFCS was for functions only, 
and that constructors (specifically) were off limits.

Am I mistaken? Is UFCS explicitly allowed for constructors? Or 
did we kind of forget to take it into account?

One of the "big" problems with allowing UFCS and constructors is 
that a "." which meant "scope" can now mean "function call". If I 
remember correctly, that is the reason why qualified calls (eg 
'a'.std.uni.toLower()) aren't allowed in UFCS (Am I correct?), 
but with constructors, you get the same problem:

Allow me to demonstrate:

--------
import std.stdio;

struct Bar
{
     struct S
     {
         int i;
     }
     enum j = 1;
}

struct S
{
     int[10] i;
}

void main()
{
     writeln(Bar.S());   (1)
     writeln(Bar.j.S()); (2)
}
--------

(1) is a standard scope call: instantiate a Bar.S. This prints 
"S(0)".
(2) is actually: "get the value j from Bar, and then UFCS 
construct an S using that J". This prints:  "S([1, 1, 1, 1, 1, 1, 
1, 1, 1, 1])"

Furthermore, I find UFCS construction confusing on the grounds 
that there is no actual "constructor function" eg: "this(...)" 
call: This is just aggregate initialization, which looks *very* 
confusing when written that way.

------------------------------------

So to sum up the question: Was UFCS + constructors are really 
desired feature? Was it taken into account? Do we want to keep it?

In particular, the "standard" workaround of "free function 
constructor" (EG "Take" vs "take") would serve much better here.
Jul 02 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:

 Is UFCS explicitly allowed for constructors? Or did we kind of 
 forget to take it into account?

I think it's allowed, but such design decisions should be written in a kind of document... instead of just in the D front end source code. See also: http://d.puremagic.com/issues/show_bug.cgi?id=9857 Bye, bearophile
Jul 02 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, July 02, 2013 09:35:38 monarch_dodra wrote:
 Coming back from learn here. There was an example where somebody
 "accidentally" called a constructor via UFCS. I am kind of
 surprised that it worked. I thought UFCS was for functions only,
 and that constructors (specifically) were off limits.
 
 Am I mistaken? Is UFCS explicitly allowed for constructors? Or
 did we kind of forget to take it into account?

I'm not sure that it was ever decided one way or the other so much as happened into being due to how UFCS was implemented. I know that it's come up before, and folks were arguing on both sides. Personally, I think that it's a horrible idea. - Jonathan M Davis
Jul 02 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 2 July 2013 at 07:35:39 UTC, monarch_dodra wrote:
 One of the "big" problems with allowing UFCS and constructors 
 is that a "." which meant "scope" can now mean "function call".

Just for the interest - try to guess what following in D may be: a.b = c.d(); This is a good example how overloaded D syntax is.
 --------

 (1) is a standard scope call: instantiate a Bar.S. This prints 
 "S(0)".
 (2) is actually: "get the value j from Bar, and then UFCS 
 construct an S using that J". This prints:  "S([1, 1, 1, 1, 1, 
 1, 1, 1, 1, 1])"

 Furthermore, I find UFCS construction confusing on the grounds 
 that there is no actual "constructor function" eg: "this(...)" 
 call: This is just aggregate initialization, which looks *very* 
 confusing when written that way.

 ------------------------------------

 So to sum up the question: Was UFCS + constructors are really 
 desired feature? Was it taken into account? Do we want to keep 
 it?

I think this worth bug issue. Even if this behavior would be proven to be correct (I guess many wish it wouldn't), bugzilla request could be posted as an ask to provide use case in D documentation site to show this behavior explicitly.
Jul 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 2 July 2013 at 08:16:38 UTC, Jonathan M Davis wrote:
 On Tuesday, July 02, 2013 09:35:38 monarch_dodra wrote:
 Coming back from learn here. There was an example where 
 somebody
 "accidentally" called a constructor via UFCS. I am kind of
 surprised that it worked. I thought UFCS was for functions 
 only,
 and that constructors (specifically) were off limits.
 
 Am I mistaken? Is UFCS explicitly allowed for constructors? Or
 did we kind of forget to take it into account?

I'm not sure that it was ever decided one way or the other so much as happened into being due to how UFCS was implemented. I know that it's come up before, and folks were arguing on both sides. Personally, I think that it's a horrible idea. - Jonathan M Davis

We are 2. that is horrible.
Jul 02 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/02/2013 09:35 AM, monarch_dodra wrote:
 Furthermore, I find UFCS construction confusing on the grounds that there is
no actual
 "constructor function" eg: "this(...)" call:  This is just aggregate
initialization,

Aggregate initialization is the job of the constructor. It is a default constructor call.
 which looks *very* confusing when written that way.

I disagree, even though the example appears to be specifically designed to confuse. Actual usage looks like this: import std.stdio, std.bigint void main(){ writeln(2.BigInt ^^ 123456); }
 ------------------------------------

 So to sum up the question: Was UFCS + constructors are really desired
 feature?

UFCS allows foo(a,b) to be written as a.foo(b), if 'foo' is not a member of a.
 Was it taken into account?

I guess so.
 Do we want to keep it?

There is no reason to artificially ban it.
 In particular, the "standard" workaround of "free function constructor"

What is the difference?
 (EG "Take" vs "take") would serve much better here.

"take" is not a "free function constructor".
Jul 02 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/02/2013 07:58 PM, Jonathan M Davis wrote:
 On Tuesday, July 02, 2013 14:46:41 Timon Gehr wrote:
 Do we want to keep it?

There is no reason to artificially ban it.

There's nothing artificial about it. Constructors are not normal functions and should not be treated as such. They're fundamentally different from normal functions. Also, in all other cases, UFCS involves using a free function as if it were a member function, so it's incredibly bizarre as well as inconsistent with the rest of UFCS to allow constructors to be used with it. - Jontahan M Davis

It is an artificial limitation, because you need to add an explicit check after symbol lookup to ban constructors. Analogies are always broken, but the rest of the post reads to me roughly like: "Dogs are not pets, and should not be treated as such. They are fundamentally different from pets. Also, there are no other pets that bark, so it's incredibly bizarre as well as inconsistent with the rest of the notion of a 'pet' to have a pet dog. - Tmion M Gehr " This has happened before. What am I missing?
Jul 02 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/02/2013 10:16 PM, Maxim Fomin wrote:
 On Tuesday, 2 July 2013 at 19:47:07 UTC, Timon Gehr wrote:
 Analogies are always broken, but the rest of the post reads to me
 roughly like:

 "Dogs are not pets, and should not be treated as such.
 They are fundamentally different from pets.

 Also, there are no other pets that bark, so it's incredibly bizarre as
 well as inconsistent with the rest of the notion of a 'pet' to have a
 pet dog.

 - Tmion M Gehr
 "

class A { this() {} void foo(){} } A a = new A; // calls ctor, not foo Of course constructors are special because not any function is called upon object construction.

(We are discussing struct constructors.) Of course. I fully agree. Obviously there is a reason why those functions are called constructors. But one could now extend on the original argument, and say that eg. all the overloading rules should be different for constructors, because they are fundamentally different and should under no circumstances be treated like 'normal functions'. Do you see what the point is? This is not a valid way of justifying a breaking language change.
 Same logic

Logics that can prove some equivalent statements are not necessarily equivalent. (In particular, it does not rule out inconsistency of one of them.)
 was made when ability to overload
 some operators was blocked. All operators are, well, operators but you
 cannot overload all of them. It appears that sometimes it does make
 sense to restrict operation on some particular elements of the set and
 sometimes not.
 ...

Such restrictions need to be justified. The justification should make (at least some) sense. There is no point in heuristically designing language features from observations about other language features without applying insight. (Anyway, I do not think that overloading of a fixed set of primitive operators using specially named member functions is a good mechanism for infix notation.)
Jul 02 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/03/2013 03:37 AM, deadalnix wrote:
 On Tuesday, 2 July 2013 at 19:47:07 UTC, Timon Gehr wrote:
 It is an artificial limitation, because you need to add an explicit
 check after symbol lookup to ban constructors.

That seems very implementation defined.

It is true for two implementations and one spec I am aware of.
 The lookup will gives you a class or struct declaration,

Hopefully the UFCS lookup gives me a fully analysed call expression. That's the point of specifying features by rewrite rules.
 so special casing the constructor is mandatory anyway.

Yes, the call expression needs some kind of check in order to support struct literals. Cancelling that support in some way in case the call expression happens to have been generated by an UFCS rewrite requires another check, which complicates the formal specification of UFCS for no gain.
Jul 02 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/02/2013 09:35 AM, monarch_dodra wrote:
 ...

 One of the "big" problems with allowing UFCS and constructors is that a
 "." which meant "scope" can now mean "function call".
 ...

I missed this point. 'One of the drawbacks of UFCS is that "bar.foo" which meant "scope lookup" or "opDispatch instantiation" or "alias this lookup" can now also mean "UFCS lookup".' Fixed.
Jul 02 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/02/2013 03:00 PM, deadalnix wrote:
 On Tuesday, 2 July 2013 at 12:57:50 UTC, Timon Gehr wrote:
 On 07/02/2013 09:35 AM, monarch_dodra wrote:
 ...

 One of the "big" problems with allowing UFCS and constructors is that a
 "." which meant "scope" can now mean "function call".
 ...

I missed this point. 'One of the drawbacks of UFCS is that "bar.foo" which meant "scope lookup" or "opDispatch instantiation" or "alias this lookup" can now also mean "UFCS lookup".' Fixed.

That is an issue, we have all of this, and prioritization mechanism is implementation defined right now.

Yup. I'll go with: 1: If member is present (current scope or super class scope), use that, otherwise try opDispatch in the same scopes. Block alias this at this point. 2: If no success, loop through all alias this definitions and apply 1. for the corresponding scopes. Collect possible members. 3: Error out if multiple possible distinct members. 4: Try UFCS rewrite if no matches. (Of course, even checking whether a member is present, or looping over all alias this definitions are not entirely trivial processes themselves in the general case.) This seems to be compatible with what DMD does.
Jul 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 2 July 2013 at 12:57:50 UTC, Timon Gehr wrote:
 On 07/02/2013 09:35 AM, monarch_dodra wrote:
 ...

 One of the "big" problems with allowing UFCS and constructors 
 is that a
 "." which meant "scope" can now mean "function call".
 ...

I missed this point. 'One of the drawbacks of UFCS is that "bar.foo" which meant "scope lookup" or "opDispatch instantiation" or "alias this lookup" can now also mean "UFCS lookup".' Fixed.

That is an issue, we have all of this, and prioritization mechanism is implementation defined right now.
Jul 02 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--089e01538d70f4009404e08745d7
Content-Type: text/plain; charset=UTF-8

2013/7/2 deadalnix <deadalnix gmail.com>

 On Tuesday, 2 July 2013 at 08:16:38 UTC, Jonathan M Davis wrote:

 On Tuesday, July 02, 2013 09:35:38 monarch_dodra wrote:

 Coming back from learn here. There was an example where somebody
 "accidentally" called a constructor via UFCS. I am kind of
 surprised that it worked. I thought UFCS was for functions only,
 and that constructors (specifically) were off limits.

 Am I mistaken? Is UFCS explicitly allowed for constructors? Or
 did we kind of forget to take it into account?

I'm not sure that it was ever decided one way or the other so much as happened into being due to how UFCS was implemented. I know that it's come up before, and folks were arguing on both sides. Personally, I think that it's a horrible idea. - Jonathan M Davis

We are 2. that is horrible.

I don't know what design decision had been there about it. Historically, there's no restriction against UFCS-callable entity. With 2.030 (released on May 11, 2009) and git head, following code completely works. void foo(int[]) {} void bar(T)(T) {} struct Foo { int[] x; } struct Bar { this(int[]) {} } struct Baz { static opCall(int[]) { return 0; } } int[] function(int[]) fp; int[] delegate(int[]) dg; struct Functor { int opCall(int[]) { return 0; } } Functor fn; void main() { fp = function(int[] x){ return x; }; dg = delegate(int[] x){ return x; }; int[] a; a.foo(); a.bar(); auto x1 = a.Foo(); auto x2 = a.Bar(); auto x3 = a.Baz(); a.fp(); a.dg(); a.fn(); } While improvement of dmd front-end code, I didn't touch it. Yes, I did never designed it... Kenji Hara --089e01538d70f4009404e08745d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /7/2 deadalnix <span dir=3D"ltr">&lt;<a href=3D"mailto:deadalnix gmail.com"= target=3D"_blank">deadalnix gmail.com</a>&gt;</span><br><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On Tuesday, 2 July 2013 at 08:16:38 UTC, Jonathan M Davis= wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"><div class=3D"im"> On Tuesday, July 02, 2013 09:35:38 monarch_dodra wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b= order-left-style:solid;padding-left:1ex"> Coming back from learn here. There was an example where somebody<br> &quot;accidentally&quot; called a constructor via UFCS. I am kind of<br> surprised that it worked. I thought UFCS was for functions only,<br> and that constructors (specifically) were off limits.<br> <br> Am I mistaken? Is UFCS explicitly allowed for constructors? Or<br> did we kind of forget to take it into account?<br> </blockquote> <br></div><div class=3D"im"> I&#39;m not sure that it was ever decided one way or the other so much as h= appened<br> into being due to how UFCS was implemented. I know that it&#39;s come up be= fore,<br> and folks were arguing on both sides. Personally, I think that it&#39;s a h= orrible<br> idea.<br> <br> - Jonathan M Davis<br> </div></blockquote> <br> We are 2. that is horrible.<br> </blockquote></div><br></div><div>I don&#39;t know what design decision had= been there about it.</div><div class=3D"gmail_extra"><br></div><div class= =3D"gmail_extra"><div>Historically, there&#39;s no restriction against UFCS= -callable entity.<br> </div><div>With 2.030 (released on May 11, 2009)=C2=A0and git head, followi= ng code completely works.</div><div><br></div><div><div><div>void foo(int[]= ) {}</div><div>void bar(T)(T) {}</div><div><br></div><div>struct Foo { int[= ] x; }</div> <div>struct Bar { this(int[]) {} }</div><div>struct Baz { static opCall(int= []) { return 0; } }</div><div><br></div><div>int[] function(int[]) fp;</div=
<div>int[] delegate(int[]) dg;</div><div><br></div><div>struct Functor { i=

<div>Functor fn;</div><div><br></div><div>void main()</div><div>{</div><div=
=C2=A0 =C2=A0 fp =3D function(int[] x){ return x; };</div><div>=C2=A0 =C2=

=C2=A0 int[] a;</div><div>=C2=A0 =C2=A0 a.foo();</div> <div>=C2=A0 =C2=A0 a.bar();</div><div>=C2=A0 =C2=A0 auto x1 =3D a.Foo();</d= iv><div>=C2=A0 =C2=A0 auto x2 =3D a.Bar();</div><div>=C2=A0 =C2=A0 auto x3 = =3D a.Baz();</div><div>=C2=A0 =C2=A0 a.fp();</div><div>=C2=A0 =C2=A0 a.dg()= ;</div><div>=C2=A0 =C2=A0 a.fn();</div><div>}</div></div><div><br></div> <div>While improvement of dmd front-end code, I didn&#39;t touch it.</div><= div>Yes, I did never designed it...<br></div></div><div style><br></div><di= v>Kenji Hara</div></div></div> --089e01538d70f4009404e08745d7--
Jul 02 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 2 July 2013 at 12:46:42 UTC, Timon Gehr wrote:
 On 07/02/2013 09:35 AM, monarch_dodra wrote:
 which looks *very* confusing when written that way.

I disagree, even though the example appears to be specifically designed to confuse. Actual usage looks like this: import std.stdio, std.bigint void main(){ writeln(2.BigInt ^^ 123456); }

Yeah... tailored for confusion... that could be the biggest issue actually: I always get surprised when arrays are 1 item initialized, and even more so when done in a struct via aggregate initialization. I'd say *that* was actually the bigger culprit in my example, and the one that lead to my confusion, which I then blamed (or "called wolf") on UFCS "If it wasn't for UFCS, that would have been turned down!" UFCS actually had nothing to do with it. :( Well, thanks for the explanation and debunk.
Jul 02 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, July 02, 2013 14:46:41 Timon Gehr wrote:
 Do we want to keep it?

There is no reason to artificially ban it.

There's nothing artificial about it. Constructors are not normal functions and should not be treated as such. They're fundamentally different from normal functions. Also, in all other cases, UFCS involves using a free function as if it were a member function, so it's incredibly bizarre as well as inconsistent with the rest of UFCS to allow constructors to be used with it. - Jontahan M Davis
Jul 02 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 2 July 2013 at 19:47:07 UTC, Timon Gehr wrote:
 Analogies are always broken, but the rest of the post reads to 
 me roughly like:

 "Dogs are not pets, and should not be treated as such.
 They are fundamentally different from pets.

 Also, there are no other pets that bark, so it's incredibly 
 bizarre as well as inconsistent with the rest of the notion of 
 a 'pet' to have a pet dog.

 - Tmion M Gehr
 "

class A { this() {} void foo(){} } A a = new A; // calls ctor, not foo Of course constructors are special because not any function is called upon object construction. Same logic was made when ability to overload some operators was blocked. All operators are, well, operators but you cannot overload all of them. It appears that sometimes it does make sense to restrict operation on some particular elements of the set and sometimes not. Anyway, without final decision on this issue, there would be endless controversy between those who point on commonness of all functions and those who point on peculiarity of some of them.
Jul 02 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 2 July 2013 at 19:47:07 UTC, Timon Gehr wrote:
 It is an artificial limitation, because you need to add an 
 explicit check after symbol lookup to ban constructors.

That seems very implementation defined. The lookup will gives you a class or struct declaration, so special casing the constructor is mandatory anyway.
Jul 02 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 2 July 2013 at 21:38:26 UTC, Timon Gehr wrote:
 Such restrictions need to be justified. The justification 
 should make (at least some) sense. There is no point in 
 heuristically designing language features from observations 
 about other language features without applying insight.

The whole point of UFCS is to be able to provide additional custom "methods" to a object (class or struct). Constructor UFCS don't fulfill that use case. Nothing is removed from the language as factories method can be introduced anyway.
Jul 02 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 07/03/2013 04:12 AM, Jonathan M Davis wrote:
 On Wednesday, July 03, 2013 04:00:45 bearophile wrote:
 deadalnix:
 The whole point of UFCS is to be able to provide additional
 custom "methods" to a object (class or struct). Constructor
 UFCS don't fulfill that use case.

 Nothing is removed from the language as factories method can be
 introduced anyway.

This frames the topic in a wrong way. Constructors are not normal functions, they are special, but functional languages show us that's it's a very good idea to see them as functions. And the original point of UFCS doesn't matter much. What matters is what are the practical disadvantages of allowing UFCSyntax for constructors (like the original post in this thread), and what are their practical advantages/uses (like a handy usage in UFCS chains). Then we take a look at what's the resulting balance and we decide. And such decisions should then become the written specifics of this part of the D design.

The primary benefit of UFCS is generic code, because if uses UFCS, generic code doesn't have to care whether a function is a member function or a free function (particularly when that can vary drastically depending on what type is used to instantiate the template).

No. Generic code has to be careful with UFCS, because every method that is called on a suitable variable via UFCS can be (accidentally) replaced by the client code.
 Construction is not and cannot be generic.

The point is that struct constructors can be generically used like other callables. import std.stdio, std.algorithm; struct S{ int x; } void main(){ auto x = [1,2,3]; writeln(x.map!S); } There is nothing to be gained from subtly breaking this analogy. UFCS can be applied to any callable. You are probably not going to like this, but the following code also works: import std.stdio; struct S{ int opCall(int x){ return x+1; } } S s; void main(){ auto x = 1; writeln(x.s); }
 The closest that you could get would be a factory function, which is
 quite different.  But constructors themselves cannot be generic. As such, using
 constructors with UFCS in generic code just doesn't work, meaning that the
 only gain that you're getting from using UFCS with constructors is that you
 get a slightly different syntax that you might like better for one reason or
 another. But I see no technical reason why it could add any benefit over simply
 calling the constructor normally. And as such, I think that allowing UFCS to
 work with constructors is definitely an anti-feature.
 ...

To be an anti-feature it has to be harmful, not just of less benefit than some other (aspect of the) feature.
Jul 02 2013
next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 07/03/13 05:21, Jonathan M Davis wrote:
 On Wednesday, July 03, 2013 04:54:41 Timon Gehr wrote:
 There is nothing to be gained from subtly breaking this analogy. UFCS
 can be applied to any callable.

 You are probably not going to like this, but the following code also works:

 import std.stdio;

 struct S{
 int opCall(int x){ return x+1; }
 }

 S s;

 void main(){
 auto x = 1;
 writeln(x.s);
 }

That is _very_ broken IMHO. It makes no sense for parens to be optional with opCall. The whole point of opCall is to overload the parens!

This is an optional-parens issue, not an UFCS issue. Ie Timon's example only works w/o property enforcement, what actually happens is "writeln(x.s())". A really bad idea - yes, but it's not an UFCS and ctor specific problem. artur
Jul 03 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07/03/2013 04:53 PM, John Colvin wrote:
 On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis wrote:
 That is _very_ broken IMHO. It makes no sense for parens to be
 optional with
 opCall. The whole point of opCall is to overload the parens!

So much about optional parenthesis is broken. I really wish things weren't going that way, it obfusticates the difference between a callable and the result in a really nasty way, and it doesn't work for function pointers (nor does UFCS unfortunately).

Yes, UFCS works.
Jul 03 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 07/03/13 17:11, John Colvin wrote:
 On Wednesday, 3 July 2013 at 15:05:29 UTC, Timon Gehr wrote:
 On 07/03/2013 04:53 PM, John Colvin wrote:
 On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis wrote:
 That is _very_ broken IMHO. It makes no sense for parens to be
 optional with
 opCall. The whole point of opCall is to overload the parens!

So much about optional parenthesis is broken. I really wish things weren't going that way, it obfusticates the difference between a callable and the result in a really nasty way, and it doesn't work for function pointers (nor does UFCS unfortunately).

Yes, UFCS works.

struct A {} void foo(A a) {} void main() { A a; auto foo_ptr = &foo; a.foo_ptr(); //Error: undefined identifier 'foo_ptr' a.foo_ptr; //Error: no property 'foo_ptr' for type 'A' }

Move the "auto foo_ptr = &foo;" line outside of `main` and it'll work. UFCS has several problems that need to be fixed and this is just one of them, but it isn't function-pointer specific. artur
Jul 03 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
deadalnix:

 The whole point of UFCS is to be able to provide additional 
 custom "methods" to a object (class or struct). Constructor 
 UFCS don't fulfill that use case.

 Nothing is removed from the language as factories method can be 
 introduced anyway.

This frames the topic in a wrong way. Constructors are not normal functions, they are special, but functional languages show us that's it's a very good idea to see them as functions. And the original point of UFCS doesn't matter much. What matters is what are the practical disadvantages of allowing UFCSyntax for constructors (like the original post in this thread), and what are their practical advantages/uses (like a handy usage in UFCS chains). Then we take a look at what's the resulting balance and we decide. And such decisions should then become the written specifics of this part of the D design. Bye, bearophile
Jul 02 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, July 03, 2013 04:00:45 bearophile wrote:
 deadalnix:
 The whole point of UFCS is to be able to provide additional
 custom "methods" to a object (class or struct). Constructor
 UFCS don't fulfill that use case.
 
 Nothing is removed from the language as factories method can be
 introduced anyway.

This frames the topic in a wrong way. Constructors are not normal functions, they are special, but functional languages show us that's it's a very good idea to see them as functions. And the original point of UFCS doesn't matter much. What matters is what are the practical disadvantages of allowing UFCSyntax for constructors (like the original post in this thread), and what are their practical advantages/uses (like a handy usage in UFCS chains). Then we take a look at what's the resulting balance and we decide. And such decisions should then become the written specifics of this part of the D design.

The primary benefit of UFCS is generic code, because if uses UFCS, generic code doesn't have to care whether a function is a member function or a free function (particularly when that can vary drastically depending on what type is used to instantiate the template). Construction is not and cannot be generic. The closest that you could get would be a factory function, which is quite different. But constructors themselves cannot be generic. As such, using constructors with UFCS in generic code just doesn't work, meaning that the only gain that you're getting from using UFCS with constructors is that you get a slightly different syntax that you might like better for one reason or another. But I see no technical reason why it could add any benefit over simply calling the constructor normally. And as such, I think that allowing UFCS to work with constructors is definitely an anti-feature. - Jonathan M Davis
Jul 02 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, July 03, 2013 04:54:41 Timon Gehr wrote:
 On 07/03/2013 04:12 AM, Jonathan M Davis wrote:
 On Wednesday, July 03, 2013 04:00:45 bearophile wrote:
 deadalnix:
 The whole point of UFCS is to be able to provide additional
 custom "methods" to a object (class or struct). Constructor
 UFCS don't fulfill that use case.
 
 Nothing is removed from the language as factories method can be
 introduced anyway.

This frames the topic in a wrong way. Constructors are not normal functions, they are special, but functional languages show us that's it's a very good idea to see them as functions. And the original point of UFCS doesn't matter much. What matters is what are the practical disadvantages of allowing UFCSyntax for constructors (like the original post in this thread), and what are their practical advantages/uses (like a handy usage in UFCS chains). Then we take a look at what's the resulting balance and we decide. And such decisions should then become the written specifics of this part of the D design.

The primary benefit of UFCS is generic code, because if uses UFCS, generic code doesn't have to care whether a function is a member function or a free function (particularly when that can vary drastically depending on what type is used to instantiate the template).

No. Generic code has to be careful with UFCS, because every method that is called on a suitable variable via UFCS can be (accidentally) replaced by the client code.

That's the whole point! If you absolutely have to be certain that it's not calling a free function, then don't use UFCS, but the primary benefits of UFCS   are making it so that generic code doesn't have to care whether a function is a free function and making it so that types can overload the behavior of free functions (e.g. having a member function find which is optimized for that type and can be used in place of std.algorithm.find).
 Construction is not and cannot be generic.

The point is that struct constructors can be generically used like other callables. import std.stdio, std.algorithm; struct S{ int x; } void main(){ auto x = [1,2,3]; writeln(x.map!S); } There is nothing to be gained from subtly breaking this analogy. UFCS can be applied to any callable. You are probably not going to like this, but the following code also works: import std.stdio; struct S{ int opCall(int x){ return x+1; } } S s; void main(){ auto x = 1; writeln(x.s); }

That is _very_ broken IMHO. It makes no sense for parens to be optional with opCall. The whole point of opCall is to overload the parens!
 The closest that you could get would be a factory function, which is
 quite different. But constructors themselves cannot be generic. As such,
 using constructors with UFCS in generic code just doesn't work, meaning
 that the only gain that you're getting from using UFCS with constructors
 is that you get a slightly different syntax that you might like better
 for one reason or another. But I see no technical reason why it could add
 any benefit over simply calling the constructor normally. And as such, I
 think that allowing UFCS to work with constructors is definitely an
 anti-feature.
 ...

To be an anti-feature it has to be harmful, not just of less benefit than some other (aspect of the) feature.

I _do_ think that it's harmful. It obfuscates code without adding any benefit. - Jonathan M Davis
Jul 02 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis wrote:
 That is _very_ broken IMHO. It makes no sense for parens to be 
 optional with
 opCall. The whole point of opCall is to overload the parens!

So much about optional parenthesis is broken. I really wish things weren't going that way, it obfusticates the difference between a callable and the result in a really nasty way, and it doesn't work for function pointers (nor does UFCS unfortunately).
Jul 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis wrote:
 On Wednesday, July 03, 2013 04:54:41 Timon Gehr wrote:
 On 07/03/2013 04:12 AM, Jonathan M Davis wrote:
 On Wednesday, July 03, 2013 04:00:45 bearophile wrote:
 deadalnix:
 The whole point of UFCS is to be able to provide additional
 custom "methods" to a object (class or struct). Constructor
 UFCS don't fulfill that use case.
 
 Nothing is removed from the language as factories method 
 can be
 introduced anyway.

This frames the topic in a wrong way. Constructors are not normal functions, they are special, but functional languages show us that's it's a very good idea to see them as functions. And the original point of UFCS doesn't matter much. What matters is what are the practical disadvantages of allowing UFCSyntax for constructors (like the original post in this thread), and what are their practical advantages/uses (like a handy usage in UFCS chains). Then we take a look at what's the resulting balance and we decide. And such decisions should then become the written specifics of this part of the D design.

The primary benefit of UFCS is generic code, because if uses UFCS, generic code doesn't have to care whether a function is a member function or a free function (particularly when that can vary drastically depending on what type is used to instantiate the template).

No. Generic code has to be careful with UFCS, because every method that is called on a suitable variable via UFCS can be (accidentally) replaced by the client code.

That's the whole point! If you absolutely have to be certain that it's not calling a free function, then don't use UFCS, but the primary benefits of UFCS   are making it so that generic code doesn't have to care whether a function is a free function and making it so that types can overload the behavior of free functions (e.g. having a member function find which is optimized for that type and can be used in place of std.algorithm.find).
 Construction is not and cannot be generic.

The point is that struct constructors can be generically used like other callables. import std.stdio, std.algorithm; struct S{ int x; } void main(){ auto x = [1,2,3]; writeln(x.map!S); } There is nothing to be gained from subtly breaking this analogy. UFCS can be applied to any callable. You are probably not going to like this, but the following code also works: import std.stdio; struct S{ int opCall(int x){ return x+1; } } S s; void main(){ auto x = 1; writeln(x.s); }

That is _very_ broken IMHO. It makes no sense for parens to be optional with opCall. The whole point of opCall is to overload the parens! - Jonathan M Davis

In a UFCS chain, it would make sense for the so-called "function object": struct Incrementor { int n; ref int opCall(ref int i) { return i+=n; } } int i, j; auto incrementByTwo = Incremementor(2); auto incrementByThree = Incremementor(3); i.incrementByTwo; j.incrementByThree; Here, the "function object" is treated just like a function (it is *designed* to behave like a function), so it should benefit from the same optional parens as a normal function. However, yeah, I think a standalone arg-less opCall with no parens is stupid (unless someone has a usecase for it?): It's an alias this in disguise, nothing more.
Jul 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 3 July 2013 at 14:53:56 UTC, John Colvin wrote:
 On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis 
 wrote:
 That is _very_ broken IMHO. It makes no sense for parens to be 
 optional with
 opCall. The whole point of opCall is to overload the parens!

So much about optional parenthesis is broken. I really wish things weren't going that way, it obfusticates the difference between a callable and the result in a really nasty way, and it doesn't work for function pointers (nor does UFCS unfortunately).

While I agree with you, I think that discussion is passed. I don't think anybody wants to resurect it (IMO).
Jul 03 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 3 July 2013 at 15:05:29 UTC, Timon Gehr wrote:
 On 07/03/2013 04:53 PM, John Colvin wrote:
 On Wednesday, 3 July 2013 at 03:22:16 UTC, Jonathan M Davis 
 wrote:
 That is _very_ broken IMHO. It makes no sense for parens to be
 optional with
 opCall. The whole point of opCall is to overload the parens!

So much about optional parenthesis is broken. I really wish things weren't going that way, it obfusticates the difference between a callable and the result in a really nasty way, and it doesn't work for function pointers (nor does UFCS unfortunately).

Yes, UFCS works.

struct A {} void foo(A a) {} void main() { A a; auto foo_ptr = &foo; a.foo_ptr(); //Error: undefined identifier 'foo_ptr' a.foo_ptr; //Error: no property 'foo_ptr' for type 'A' }
Jul 03 2013