http://d.puremagic.com/issues/show_bug.cgi?id=3680


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au
           Severity|normal                      |enhancement


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3680



--- Comment #4 from Michel Nolard <michel.nolard@gmail.com> 2010-01-15 03:13:06 PST ---
Ok. I clearly see your point now, and it is both practical and logical ... and I agree ! This would be quite an improvement for a lot of situations.

What bothers me is this :
> To remove static opCall's completely is another subject...
In fact, your proposal - which is a good one - implies from "the opCall and default constructor removal" problem to be solved at the same time.

Imagine someone relying upon the constructor removal "feature" you depict and who would not be able to make things work in a new version. This can not be admitted. Both problems must definitely be solved and their solution's integration be planned for the same release.

A case which needs clarification, by the way, is when the struct is externalized to C which does not prohibits the default construction to be used...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3680



--- Comment #5 from ibrahim YANIKLAR <yanikibo@gmail.com> 2010-01-15 08:43:21 PST ---
> What bothers me is this :
> > To remove static opCall's completely is another subject...

I will explain that by opening a new issue.

> A case which needs clarification, by the way, is when the struct is externalized to C which does not prohibits the default construction to be used...

The implementation of the default constructor should be prohibited as the current situation. Also the implementation of the default opCall (static ... opCall()) should be prohibited. And implementing a non-default constructor or a non default opCall should not cause the removal of the defaults.

------------------------------
struct S {
  ...
  this() { ... } // should give error
}
------------------------------
struct S {
  ...
  static S opCall() { ... } // should give error
}
------------------------------
struct S {
  ...
  this(int a) { ... }
  static S opcall(double d) { ... }
}

S s = S(); // should work
S* s = new S(); // should work
------------------------------

Is this proposal causes a problem like you have depicted? Probably I could not understand your case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3680



--- Comment #6 from ibrahim YANIKLAR <yanikibo@gmail.com> 2010-01-15 09:57:39 PST ---
Also "this(int a = 0)" and "static ... opCall(int a = 0)" should be prohibited.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3680



--- Comment #7 from Don <clugdbug@yahoo.com.au> 2010-01-15 11:45:32 PST ---
(In reply to comment #6)
> Also "this(int a = 0)" and "static ... opCall(int a = 0)" should be prohibited.

That's bug 3438. I think the underlying issue is, that we need this() with no
parameters.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3680



--- Comment #8 from Michel Nolard <michel.nolard@gmail.com> 2010-01-19 02:50:53 PST ---
* This comment is more a remainder for myself than a new comment. *

There is a way to introduce a opAssign( typeof( this ) rhs ) using templates, although it is prohibited. The technique can be _accidentally_ (I ensure you this really happens) used to add a opCall or this with the wrong signature. This is based on the fact that the template's type inference occurs at a different time than the opAssign's signature validation.

I just have to find back where I used it to give you an example to be sure that that case also is managed in the proposal.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------