On Tue, 02 Sep 2008 22:42:06 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Struct constructors!
>
>http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.035.zip
>
>http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.019.zip

Thanks! Two questions about the struct constructors:

1. Why is there the limitation that the constructor list may not be empty? One problem with that rule is incorrect handling of a single parameter with a default value:

    struct S
    {
        this(int x = 1)
        {
            writefln("Ctor");
        }
    }

    S s = S();

The constructor is not called. Is such a parameter list considered empty or non-empty?


2. How do constructiors affect static opCalls?

struct S
{
	this(int x)
	{
	}

	static void opCall(int x, int y)
	{
	}
}

S s;
s(1, 2);

Error: constructor Test.main.S.this (int x) does not match parameter
types (int,int)


dmd seems to ignore static opCalls completely, if there is a constructor. Is it intended behavior?

Max Samukha wrote:
> On Tue, 02 Sep 2008 22:42:06 -0700, Walter Bright
> <newshound1@digitalmars.com> wrote:
> 
>> Struct constructors!
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.035.zip
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.019.zip
> 
> Thanks! Two questions about the struct constructors:
> 
> 1. Why is there the limitation that the constructor list may not be
> empty? One problem with that rule is incorrect handling of a single
> parameter with a default value:
> 
>     struct S
>     {
>         this(int x = 1)
>         {
>             writefln("Ctor");
>         }
>     }
> 
>     S s = S();
> 
> The constructor is not called. Is such a parameter list considered
> empty or non-empty?

Empty.



> 2. How do constructiors affect static opCalls?
> 
> struct S
> {
> 	this(int x)
> 	{
> 	}
> 
> 	static void opCall(int x, int y)
> 	{
> 	}
> }
> 
> S s;
> s(1, 2); 
> 
> Error: constructor Test.main.S.this (int x) does not match parameter
> types (int,int)
> 
> 
> dmd seems to ignore static opCalls completely, if there is a
> constructor. Is it intended behavior?

Yes, that's exactly how it works.

Extrawurst wrote:
> yeah i figured, but if i have an opCall with the exact same arguments its never called, isnt that ambiguous ? what happens to opcall anyway ? will it sooner or later fall out ?
> 
> Walter Bright wrote:
>> To construct an object of struct S:
>>
>> auto s = S(arguments);
>>
>> Extrawurst wrote:
>>> Are opCalls deprecated now ? how do i call the ctor and how the opCall? a short example in the docs would have been nice.

ctor's override the opCalls. The opCalls will eventually probably get deprecated.

On Wed, 03 Sep 2008 00:57:40 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Max Samukha wrote:
>> On Tue, 02 Sep 2008 22:42:06 -0700, Walter Bright <newshound1@digitalmars.com> wrote:
>> 
>>> Struct constructors!
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.035.zip
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.019.zip
>> 
>> Thanks! Two questions about the struct constructors:
>> 
>> 1. Why is there the limitation that the constructor list may not be empty? One problem with that rule is incorrect handling of a single parameter with a default value:
>> 
>>     struct S
>>     {
>>         this(int x = 1)
>>         {
>>             writefln("Ctor");
>>         }
>>     }
>> 
>>     S s = S();
>> 
>> The constructor is not called. Is such a parameter list considered empty or non-empty?
>
>Empty.

Should it be a compile time error? The above is semantically equivalent to

struct S
{
	this()
	{
		this(1);
	}

	this(int x)
	{
	}
}

which is not allowed.

Incidentally, calling other constructors from a constructor doesn't work. Is it a bug?

>
>
>
>> 2. How do constructiors affect static opCalls?
>> 
>> struct S
>> {
>> 	this(int x)
>> 	{
>> 	}
>> 
>> 	static void opCall(int x, int y)
>> 	{
>> 	}
>> }
>> 
>> S s;
>> s(1, 2);

Correction: should be "S(1, 2);". "S s;" is not needed.
>> 
>> Error: constructor Test.main.S.this (int x) does not match parameter
>> types (int,int)
>> 
>> 
>> dmd seems to ignore static opCalls completely, if there is a constructor. Is it intended behavior?
>
>Yes, that's exactly how it works.

Max Samukha wrote:
> Incidentally, calling other constructors from a constructor doesn't
> work. Is it a bug? 

I'd forgotten about that. It's a bug.

Walter Bright wrote:
> Extrawurst wrote:
>> yeah i figured, but if i have an opCall with the exact same arguments its never called, isnt that ambiguous ? what happens to opcall anyway ? will it sooner or later fall out ?
>>
>> Walter Bright wrote:
>>> To construct an object of struct S:
>>>
>>> auto s = S(arguments);
>>>
>>> Extrawurst wrote:
>>>> Are opCalls deprecated now ? how do i call the ctor and how the opCall? a short example in the docs would have been nice.
> 
> ctor's override the opCalls. The opCalls will eventually probably get deprecated.


Well the advandage of opCall is (in my intention) that you can have an empty argument list. it think its kind of inconsistend if u want to do reference counting in a generic struct template, isnt it ?

Walter Bright Wrote:

> Extrawurst wrote:
> > yeah i figured, but if i have an opCall with the exact same arguments its never called, isnt that ambiguous ? what happens to opcall anyway ? will it sooner or later fall out ?
> > 
> > Walter Bright wrote:
> >> To construct an object of struct S:
> >>
> >> auto s = S(arguments);
> >>
> >> Extrawurst wrote:
> >>> Are opCalls deprecated now ? how do i call the ctor and how the opCall? a short example in the docs would have been nice.
> 
> ctor's override the opCalls. The opCalls will eventually probably get deprecated.


opCalls are much more flexible than ctor's because their return type may vary or they may not have return type. I vote against deprecating them. Let whoever likes ctors use them and whoever likes opCalls use these.

Regards

Walter Bright a écrit :
> To construct an object of struct S:
> 
> auto s = S(arguments);

Please add this example to the docs. I first thought you'd create a struct like

auto s = new S(arguments);

(so that constructing something has a consistent syntax... so if then you decide to change your struct to a class, or viceversa, and you don't have to change a lot of bits everywhere)

> 
> Extrawurst wrote:
>> Are opCalls deprecated now ? how do i call the ctor and how the opCall? a short example in the docs would have been nice.

Ary Borenszweig wrote:
> Walter Bright a écrit :
>> To construct an object of struct S:
>>
>> auto s = S(arguments);
> 
while you are talking about, sorry to ask but what is the use of this keyword ?

When I look at documentation I can read :
The auto attribute is used when there are no other attributes and type inference is desired.

In which case you want inference type ? Is it a kind o C++ RTTI ?
In the sample code above, you already know that struct is of kind S.
First I thought auto means automatically destruct object when out of scope.








> Please add this example to the docs. I first thought you'd create a struct like
> 
> auto s = new S(arguments);
> 
> (so that constructing something has a consistent syntax... so if then you decide to change your struct to a class, or viceversa, and you don't have to change a lot of bits everywhere)
> 
>>
>> Extrawurst wrote:
>>> Are opCalls deprecated now ? how do i call the ctor and how the opCall? a short example in the docs would have been nice.

Mosfet wrote:
> When I look at documentation I can read :
> The auto attribute is used when there are no other attributes and type inference is desired.
> 
> In which case you want inference type ? Is it a kind o C++ RTTI ?
> In the sample code above, you already know that struct is of kind S.
> First I thought auto means automatically destruct object when out of scope.

auto just helps writing code in a more brief and readable way. The compiler infers the type which u are using by the right side of the expression, which is extremly handy when u use cascaded templates a lot.

example:
MyTemplateA!(MyTemplateB("foo")) variablename = new MyTemplateA!(MyTemplateB("foo"))("aParemterString");

with auto u just have to write it once:
auto variablename = new MyTemplateA!(MyTemplateB("foo"))("aParemterString");

the compiler infers the type of variablename looking at the expression.