September 20, 2012
On Wednesday, 19 September 2012 at 12:31:08 UTC, Maxim Fomin wrote:
> On Wednesday, 19 September 2012 at 11:51:13 UTC, monarch_dodra wrote:
>> The biggest issue with not having a no-arg constructor can easilly be seen if you have ever worked with a "Reference Semantic" semantic struct: A struct that has a pointer to a payload. Basically, a class, but without the inherited Object polymorphism.
>
> This means that you still have a class object. What is design behind inserting class into the structure for the sake of escaping from classes?
>

That's not the point at all. For starters, the "Payload" is another struct, NOT a class wrapped in a struct.

As for why we aren't using a class to begin with? First, because a class wraps much more than we want: polymorphism, adherence to a base "Object Type", virtual opEquals, RTTI...

But mostly, because the object we manipulate is a struct and has always been a struct. It uses reference semantics, but is in dire need of a an initialization to default.

On Wednesday, 19 September 2012 at 14:09:10 UTC, deadalnix wrote:
> Le 19/09/2012 15:24, Timon Gehr a écrit :
>> I don't think making the use of optional parens affect semantics is an
>> idea worth following.
>
> I have to agree with that.
>
> However, argument-less constructor is something required for struct. The problem is raised on a regular basis on this newsgroup, and some solution already have been proposed.
>
> As discussed earlier in the reference thread, the compiler will have to track down initialization at some point. A struct with an argument-less constructor which isn't initialized must be an error. This will avoid the () semantic dichotomy while solving that problem.
Would you happen to have some links to those proposed solutions, or reword them here for us?
September 20, 2012
On Thursday, 20 September 2012 at 00:14:04 UTC, Jonathan M Davis
wrote:
> On Thursday, September 20, 2012 00:12:04 Felix Hufnagel wrote:
>> isn't it even worse?
>> 
>> import std.stdio;
>> struct S
>> {
>> int i;
>> this(void* p = null){this.i = 5;}
>> }
>> void main()
>> {
>> //S l(); //gives a linker error
>> auto k = S();
>> writeln(k.i); //prints 0
>> }
>
> Of course that generates a linker error. You just declared a function without
> a body.
>
> - Jonathan M Davis

sure, but it's a bit unexpected. do we need to be able to declare
empty functions?

but whats even more confusing: you are not allowed to declare an
no_arg constructor. but you are allowed to declare one where all
parameters have default parameters. but then, how to call it
without args? auto k = S(); doesn't work?


September 20, 2012
On Thursday, September 20, 2012 10:11:41 Felix Hufnagel wrote:
> On Thursday, 20 September 2012 at 00:14:04 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, September 20, 2012 00:12:04 Felix Hufnagel wrote:
> >> isn't it even worse?
> >> 
> >> import std.stdio;
> >> struct S
> >> {
> >> int i;
> >> this(void* p = null){this.i = 5;}
> >> }
> >> void main()
> >> {
> >> //S l(); //gives a linker error
> >> auto k = S();
> >> writeln(k.i); //prints 0
> >> }
> > 
> > Of course that generates a linker error. You just declared a
> > function without
> > a body.
> > 
> > - Jonathan M Davis
> 
> sure, but it's a bit unexpected. do we need to be able to declare empty functions?

It can be useful at module scope, and it would complicate the grammar to make it anything else at function scope, even if there's no practical reason to use it that way there. C/C++ (which doesn't have nested functions) also treats that declaration as a function declaration.

> but whats even more confusing: you are not allowed to declare an no_arg constructor. but you are allowed to declare one where all parameters have default parameters. but then, how to call it without args? auto k = S(); doesn't work?

It's a bug. I'm pretty sure that there's a bug report for it already, but I'd have to go digging for it to know which one it is.

- Jonathan M Davis
September 20, 2012
The only thing I really miss is:


class Foo {}

struct Bar {
    Foo foo = new Foo();
}

void main() {
    Bar s = Bar();
    assert(s.foo !is null);
}
September 20, 2012
On Thursday, 20 September 2012 at 09:22:39 UTC, David wrote:
> The only thing I really miss is:
>
>
> class Foo {}
>
> struct Bar {
>     Foo foo = new Foo();
> }
>
> void main() {
>     Bar s = Bar();
>     assert(s.foo !is null);
> }

That probably won't _ever_ work, because that is a default *instruction*, not a default *value*.

It is a default constructor in disguise :D which is a no-no, as it would break all of D's move semantics (which are pretty awesome, IMO).

September 20, 2012
Le 20/09/2012 08:26, monarch_dodra a écrit :
> On Wednesday, 19 September 2012 at 12:31:08 UTC, Maxim Fomin wrote:
>> On Wednesday, 19 September 2012 at 11:51:13 UTC, monarch_dodra wrote:
>>> The biggest issue with not having a no-arg constructor can easilly be
>>> seen if you have ever worked with a "Reference Semantic" semantic
>>> struct: A struct that has a pointer to a payload. Basically, a class,
>>> but without the inherited Object polymorphism.
>>
>> This means that you still have a class object. What is design behind
>> inserting class into the structure for the sake of escaping from classes?
>>
>
> That's not the point at all. For starters, the "Payload" is another
> struct, NOT a class wrapped in a struct.
>
> As for why we aren't using a class to begin with? First, because a class
> wraps much more than we want: polymorphism, adherence to a base "Object
> Type", virtual opEquals, RTTI...
>
> But mostly, because the object we manipulate is a struct and has always
> been a struct. It uses reference semantics, but is in dire need of a an
> initialization to default.
>
> On Wednesday, 19 September 2012 at 14:09:10 UTC, deadalnix wrote:
>> Le 19/09/2012 15:24, Timon Gehr a écrit :
>>> I don't think making the use of optional parens affect semantics is an
>>> idea worth following.
>>
>> I have to agree with that.
>>
>> However, argument-less constructor is something required for struct.
>> The problem is raised on a regular basis on this newsgroup, and some
>> solution already have been proposed.
>>
>> As discussed earlier in the reference thread, the compiler will have
>> to track down initialization at some point. A struct with an
>> argument-less constructor which isn't initialized must be an error.
>> This will avoid the () semantic dichotomy while solving that problem.
> Would you happen to have some links to those proposed solutions, or
> reword them here for us?

My solution was to include code analysis in the compiler in order to ensure that a struct with an argument-less constructor is assigned before being used.

struct S {
    this() {}
}

S s;
foo(s); // Error, s may not have been initialized

s = S();
foo(s); // OK

S.init contains the struct memory layout as it is before any constructor run on them. It is not @safe to use in on a struct with a default argument.

Note that the code analysis required for such a task is planed to be included in dmd, to support @disable this(); anyway.
September 20, 2012
Le 20/09/2012 00:12, Felix Hufnagel a écrit :
> isn't it even worse?
>
> import std.stdio;
> struct S
> {
> int i;
> this(void* p = null){this.i = 5;}
> }
> void main()
> {
> //S l(); //gives a linker error
> auto k = S();
> writeln(k.i); //prints 0
> }

Last time I checked it, it was not working. No constructor was called.
September 20, 2012
On 20/09/12 11:09, Jonathan M Davis wrote:
> On Thursday, September 20, 2012 10:11:41 Felix Hufnagel wrote:
>> On Thursday, 20 September 2012 at 00:14:04 UTC, Jonathan M Davis
>>
>> wrote:
>>> On Thursday, September 20, 2012 00:12:04 Felix Hufnagel wrote:
>>>> isn't it even worse?
>>>>
>>>> import std.stdio;
>>>> struct S
>>>> {
>>>> int i;
>>>> this(void* p = null){this.i = 5;}
>>>> }
>>>> void main()
>>>> {
>>>> //S l(); //gives a linker error
>>>> auto k = S();
>>>> writeln(k.i); //prints 0
>>>> }
>>>
>>> Of course that generates a linker error. You just declared a
>>> function without
>>> a body.
>>>
>>> - Jonathan M Davis
>>
>> sure, but it's a bit unexpected. do we need to be able to declare
>> empty functions?
>
> It can be useful at module scope, and it would complicate the grammar to make
> it anything else at function scope, even if there's no practical reason to use
> it that way there. C/C++ (which doesn't have nested functions) also treats
> that declaration as a function declaration.
>
>> but whats even more confusing: you are not allowed to declare an
>> no_arg constructor. but you are allowed to declare one where all
>> parameters have default parameters. but then, how to call it
>> without args? auto k = S(); doesn't work?
>
> It's a bug. I'm pretty sure that there's a bug report for it already, but I'd
> have to go digging for it to know which one it is.
>
> - Jonathan M Davis

Bug 3438



September 20, 2012
On 09/20/2012 10:11 AM, Felix Hufnagel wrote:
> ...
> but whats even more confusing: you are not allowed to declare an
> no_arg constructor. but you are allowed to declare one where all
> parameters have default parameters. but then, how to call it
> without args? auto k = S(); doesn't work?
>
>

struct S{
    this(int=0){}
}
void main(){
    S s;
    s.__ctor();
}
1 2
Next ›   Last »