>> But there is one trouble.<br><br>I don't see the trouble.<div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
struct Foo<br>{<br> int[] arr;<br> this()//can be interpreted at compile time<br> {<br> arr = new int[3];<br> arr[0] = 1;<br> arr[1] = 2;<br> arr[2] = 3;<br> }<br>}<br>semantically, all new instances of Foo must get separate instance of array.</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Foo f1;<br>Foo f2;<br>assert(f1.arr.ptr !is f2.arr.ptr); //expects put FAILS </blockquote>
<div><br></div><div>We should have assert(f1.arr.ptr is f2.arr.ptr); as well as assert(f1 is f2); which is consistent with having Foo.init be known at compile time ( we have physical equality, not just logical equality). There's no way around that.</div>
<div><br></div><div>So the only question is whether to call the default constructor as static this() or this() (with implicitly knowing that it should be callable at compile time). I think static this() makes it clearer.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On Fri, May 17, 2013 at 4:07 PM, Igor Stepanov <span dir="ltr"><<a href="mailto:wazar.leollone@yahoo.com" target="_blank">wazar.leollone@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, 17 May 2013 at 22:45:01 UTC, Timothee Cour wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Although I agree that having a default constructor would be convenient, I<br>
think the problem is that S.init should be known at compile time by the<br>
spec.<br>
<br>
Maybe we could support the following syntax, with a static this instead of<br>
this :<br>
<br>
struct S<br>
{<br>
int x=11;<br>
int y = void;<br>
<br></div>
static this() // hypothetical<div class="im"><br>
{<br>
// x would already be initialized to int.init here<br>
assert(x == int.init);<br>
// y is left uninitialized here<br></div><div class="im">
y=x*x;<br>
}<br>
}<br>
<br>
On Fri, May 17, 2013 at 2:34 PM, Andrej Mitrovic <<a href="mailto:andrej.mitrovich@gmail.com" target="_blank">andrej.mitrovich@gmail.com</a><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
</blockquote>
<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 5/17/13, Walter Bright <<a href="mailto:walter@digitalmars.com" target="_blank">walter@digitalmars.com</a>> wrote:<br>
> I oppose this. D has a lot of nice features because of the > .init<br>
property.<br>
> Default constructors wreck that.<br>
<br>
Would they? I'm thinking the process would be:<br>
<br>
struct S<br>
{<br>
int x;<br>
int y = void;<br>
<br>
this() // hypothetical<br>
{<br>
// x would already be initialized to int.init here<br>
assert(x == int.init);<br>
<br>
// y is left uninitialized here<br>
}<br>
}<br>
<br>
Maybe that's already clear. But why is .init actually such a big<br>
problem? If it becomes arbitrarily expensive to call .init of a<br>
struct, well it's because it has to be - if the user really provided<br>
an expensive default ctor. But it's entirely the user's<br>
responsibility. So then .init can even throw, but throwing exceptions<br>
isn't a big deal. Is there some other problem?<br>
<br>
A custom default ctor in a struct is one of the most asked for<br>
features. Just yesterday we spent several hours explaining to a C++<br>
user why a default ctor doesn't work, and what .init is for. The whole<br>
conversation could have been avoided if D had support for custom<br>
default ctors for structs. This topic comes up very often in IRC and<br>
the forums.<br>
</blockquote></div></div></blockquote>
<br>
May be we can allow default ctor, but ensure that it can be<br>
interpreted at compile time and initialize .init value with<br>
ctored value?<br>
Foo.init = Foo(); //somewhere in deep of compiler<br>
<br>
But there is one trouble.<br>
<br>
struct Foo<br>
{<br>
int[] arr;<br>
this()//can be interpreted at compile time<br>
{<br>
arr = new int[3];<br>
arr[0] = 1;<br>
arr[1] = 2;<br>
arr[2] = 3;<br>
}<br>
}<br>
<br>
semantically, all new instances of Foo must get separate instance<br>
of array.<br>
<br>
Foo f1;<br>
Foo f2;<br>
assert(f1.arr.ptr !is f2.arr.ptr); //expects put FAILS<br>
<br>
However, if Foo.init initialized by compiler with Foo() and f1<br>
and f2 will be initialized with Foo.init, f1.arr and f2.arr will<br>
be the same value.<br>
<br>
We can also restrict creating of any mutable reference instances<br>
in this() constructor:<br>
<br>
struct Foo<br>
{<br>
int[] arr;<br>
immutable int[] arr2;<br>
this()//can be interpreted at compile time<br>
{<br>
arr = new int[3]; //NG<br>
arr = [1,2,3]; //NG<br>
arr2 = [1,2,3]; //OK, because arr2 is immutable and all<br>
instances of foo can contains an single array instance<br>
<br>
}<br>
}<br>
<br>
But this way is so difficult and isn't much profitable.<br>
<br>
<br>
<br>
</blockquote></div><br></div></div>