[Issue 3680] default struct constructor should not be removed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3680

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #9 from RazvanN  ---
This has been fixed. Both lines in test case 1) compile now and for test case
2) a deprecation is issued. I am referring to the test cases in the original
bug report. Closing as fixed.

--

[Issue 3680] default struct constructor should not be removed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3680

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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



--- Comment #8 from Michel Nolard michel.nol...@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: ---

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au
   Severity|normal  |enhancement


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

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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



--- Comment #4 from Michel Nolard michel.nol...@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: ---

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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



--- Comment #5 from ibrahim YANIKLAR yanik...@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: ---

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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



--- Comment #6 from ibrahim YANIKLAR yanik...@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: ---

[Issue 3680] default struct constructor should not be removed

[d-bugmail]

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



--- Comment #7 from Don clugd...@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: ---