• Uriel (19/19) Nov 29 2009 Lets consider following code:
• Daniel Keep (8/15) Nov 29 2009 isn't much more typing, and makes it explicit what's going on. Consider
• Walter Bright (3/9) Nov 29 2009 C++ has such conversions, and the trouble happens when there are two
• Uriel (5/15) Nov 29 2009 Definately, I just hadn't thought about situation where there is many
• Matti Niemenmaa (5/29) Nov 29 2009 This feature already exists, you just need to declare append and foo a
• Uriel (5/37) Nov 29 2009 Hm, very interesting, thanks. Anyway this will work only if the source
• Ellery Newcomer (5/9) Nov 29 2009 You're supposed to assume that obj is allocated on the stack, though,
• dsimcha (5/24) Nov 29 2009 It's gratuitous complexity. Anytime you add complexity to the language,...

Uriel <uriel inbox.ru> writes:

Lets consider following code:

class Foo {
   private Foo[] m_SomeData;

   public this(int a, double b, string c) {}

   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
}

void foo(Foo obj) {}

void main() {
   foo(1, 1.0, "1");

   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
}

Why not to do implicitly cast of these three parameters to new Foo 
object. We know that bar should recieve a Foo object and we have a call 
with parameters which exactly match one of Foo's constructors. It could 
be a nice syntactic sugar though not very hard to implement I think.

Daniel Keep <daniel.keep.lists gmail.com> writes:

Uriel wrote:
 ...
 
 Why not to do implicitly cast of these three parameters to new Foo
 object. We know that bar should recieve a Foo object and we have a call
 with parameters which exactly match one of Foo's constructors. It could
 be a nice syntactic sugar though not very hard to implement I think.

Why allow it?

 foo(new Foo(1, 1.0, "1"))

isn't much more typing, and makes it explicit what's going on.  Consider
it from a maintenance perspective: with this addition, you can't
actually tell what's being called.  Is it that foo function there, or is
there another overload somewhere in the imports that takes those
arguments?  There should be a very good reason for having any form of
"magic" syntax.

Walter Bright <newshound1 digitalmars.com> writes:

Daniel Keep wrote:
 isn't much more typing, and makes it explicit what's going on.  Consider
 it from a maintenance perspective: with this addition, you can't
 actually tell what's being called.  Is it that foo function there, or is
 there another overload somewhere in the imports that takes those
 arguments?  There should be a very good reason for having any form of
 "magic" syntax.

C++ has such conversions, and the trouble happens when there are two 
many possible conversions. One loses track of what is happening.

Uriel <uriel inbox.ru> writes:

Walter Bright wrote:
 Daniel Keep wrote:
 isn't much more typing, and makes it explicit what's going on.  Consider
 it from a maintenance perspective: with this addition, you can't
 actually tell what's being called.  Is it that foo function there, or is
 there another overload somewhere in the imports that takes those
 arguments?  There should be a very good reason for having any form of
 "magic" syntax.

 
 C++ has such conversions, and the trouble happens when there are two 
 many possible conversions. One loses track of what is happening.

Definately, I just hadn't thought about situation where there is many 
classes with matching contructors. And keeping this behavior only for 
the case of one possible conversion would just complicate the code.
It's all the laziness. :)

Matti Niemenmaa <see_signature for.real.address> writes:

Uriel wrote:
 class Foo {
   private Foo[] m_SomeData;
 
   public this(int a, double b, string c) {}
 
   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
 }
 
 void foo(Foo obj) {}
 
 void main() {
   foo(1, 1.0, "1");
 
   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }
 
 Why not to do implicitly cast of these three parameters to new Foo 
 object. We know that bar should recieve a Foo object and we have a call 
 with parameters which exactly match one of Foo's constructors. It could 
 be a nice syntactic sugar though not very hard to implement I think.

This feature already exists, you just need to declare append and foo a 
bit differently:

public Foo append(Foo obj...) {}
void foo(Foo obj...) {}

Uriel <uriel inbox.ru> writes:

Matti Niemenmaa wrote:
 Uriel wrote:
 class Foo {
   private Foo[] m_SomeData;

   public this(int a, double b, string c) {}

   public Foo append(Foo obj) {
     m_SomeData ~= obj;
     return this;
   }
 }

 void foo(Foo obj) {}

 void main() {
   foo(1, 1.0, "1");

   Foo obj = new Foo();
   obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }

 Why not to do implicitly cast of these three parameters to new Foo 
 object. We know that bar should recieve a Foo object and we have a 
 call with parameters which exactly match one of Foo's constructors. It 
 could be a nice syntactic sugar though not very hard to implement I 
 think.

 
 This feature already exists, you just need to declare append and foo a 
 bit differently:
 
 public Foo append(Foo obj...) {}
 void foo(Foo obj...) {}

Hm, very interesting, thanks. Anyway this will work only if the source 
code is available.
But in general I'd agree that may be this isn't worth possible troubles 
in the future. It was just an idea. :)

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

On 11/29/2009 03:45 AM, Matti Niemenmaa wrote:
 This feature already exists, you just need to declare append and foo a
 bit differently:

 public Foo append(Foo obj...) {}
 void foo(Foo obj...) {}

You're supposed to assume that obj is allocated on the stack, though, 
which requires you to make a copy of it if you want to use it later, 
which obviates the point of the syntax. I haven't found this feature to 
be useful.

dsimcha <dsimcha yahoo.com> writes:

== Quote from Uriel (uriel inbox.ru)'s article
 Lets consider following code:
 class Foo {
    private Foo[] m_SomeData;
    public this(int a, double b, string c) {}
    public Foo append(Foo obj) {
      m_SomeData ~= obj;
      return this;
    }
 }
 void foo(Foo obj) {}
 void main() {
    foo(1, 1.0, "1");
    Foo obj = new Foo();
    obj.append(1, 1.0, "1").append(2, 2.0, "2");
 }
 Why not to do implicitly cast of these three parameters to new Foo
 object. We know that bar should recieve a Foo object and we have a call
 with parameters which exactly match one of Foo's constructors. It could
 be a nice syntactic sugar though not very hard to implement I think.

It's gratuitous complexity.  Anytime you add complexity to the language, it
should
have to remove enough complexity from user code to justify the complication of
the
language.  IMHO the amount of complexity added to the language here would be
orders of magnitude less than the amount removed from user code.