On 4/9/14, Brian Schott <briancschott@gmail.com> wrote:
> Really? What does this program print using a current version of DMD?
>
> import std.stdio;
>
> struct SomeStruct
> {
> 	this(int i = 10)
> 	{
> 		this.i = i;
> 	}
> 	int i;
> }
>
> void main(string[] args)
> {
> 	auto s = SomeStruct();
> 	writeln("s.i = ", s.i);
> }

This is a current bug that is going to be fixed: https://github.com/D-Programming-Language/dmd/pull/1397

On Thursday, 10 April 2014 at 11:39:16 UTC, Andrej Mitrovic wrote:
> On 4/9/14, Brian Schott <briancschott@gmail.com> wrote:
>> Really? What does this program print using a current version of
>> DMD?
>>
>> import std.stdio;
>>
>> struct SomeStruct
>> {
>> 	this(int i = 10)
>> 	{
>> 		this.i = i;
>> 	}
>> 	int i;
>> }
>>
>> void main(string[] args)
>> {
>> 	auto s = SomeStruct();
>> 	writeln("s.i = ", s.i);
>> }
>
> This is a current bug that is going to be fixed:
> https://github.com/D-Programming-Language/dmd/pull/1397


Please do not forget about C++ porting problems that are related to this.
The code from C++ should compile and work as expected or does not compile at all and give meaningful error message.
Right now it compiles but does not work at all.
This struct constructor problem is one of the ground why I have stopped porting code to D.
I hope there will be proper solution soon.

+1

Atila

>
> Yeah. For sure.
>
> Or a named function: auto foo = foo();
> Or a make template:  auto foo = make!Foo();
> Or a dummy argument: auto foo = Foo(Foo.dummy);
> Or ditto with a global dummy:  auto foo = Foo(dummyArg);
> Or use a static opCall:        auto foo = Foo();
> Or use an initialize function: Foo foo; foo.initialize();
>
> I mean: Why complain when there are at least 10 *different* solutions at our disposal? Who doesn't love re-inventing the same functionality over and over and over again? But more importantly, who doesn't just *love* reading the documentation that explains *which* approach the damn type chose for run-time initialization. Yummy!
>
> Also, any kind of "Factory" solution has a postblit overhead if you try to emplace it. Or would require a temporary with some complex "uninitializedMove". No postblit, but still overhead.
>
> --------
>
> Being serious again, if the language isn't going to do something to address the issue, we *should* have a uniform library solution.
>
> I think the "make" template could be a good approach. It could be a universal construction scheme, with "opt-in" no-arg construction:
>
> static struct NoArg {}
> enum noArgToken;
>
> template make(T)
> {
>     //And some switches to handle non-struct types too.
>
>     T make(Args...)(auto ref Args args)
>     {
>         static if (Args.length)
>             return T(args);
>         else
>         {
>             static if (is(typeof(T(noArgToken))));
>                 return T(noArgToken);
>             else
>                 return T();
>         }
>     }
> }
>
> struct S1
> {
>     int* p;
>     @disable this();
>     this(NoArg) //Opt-in no-arg constructor
>     {p = new int;}
> }
> struct S2
> {
>     int i;
> }
>
> void main()
> {
>     S1 s11; //FAils to compile (disabled this());
>     auto s12 = S1.init; //Explicit request for static default initialization;
>     auto s13 = make!S1(); //run-time construction request.
>
>     auto s2 = make!S2(); //run-time construction request. Does nothing particular.
> }
>
> This has the advantage (IMO) of being explicit and universal. Also, it's an actual construction scheme, so `emplace(noArgToken)` would call an actual constructor.
>
> Furthermore, it could also allow a universal construction scheme for items, regardless of struct/class/integral etc...

On 2014-04-10 17:21, Remo wrote:

> Please do not forget about C++ porting problems that are related to this.
> The code from C++ should compile and work as expected or does not
> compile at all and give meaningful error message.
> Right now it compiles but does not work at all.
> This struct constructor problem is one of the ground why I have stopped
> porting code to D.
> I hope there will be proper solution soon.

How said anything about that? It has been said that one should be able to paste C code in a D file and have it compile with the same resulting semantics as in C or not compile at all. But never for C++.

-- 
/Jacob Carlborg

On Thursday, 10 April 2014 at 19:28:16 UTC, Jacob Carlborg wrote:
> On 2014-04-10 17:21, Remo wrote:
>
>> Please do not forget about C++ porting problems that are related to this.
>> The code from C++ should compile and work as expected or does not
>> compile at all and give meaningful error message.
>> Right now it compiles but does not work at all.
>> This struct constructor problem is one of the ground why I have stopped
>> porting code to D.
>> I hope there will be proper solution soon.
>
> How said anything about that? It has been said that one should be able to paste C code in a D file and have it compile with the same resulting semantics as in C or not compile at all. But never for C++.

Well, it's true that the idea is that you can copy paste C code into D and it "just works", keeping the same semantics (provided minor/trivial tweaks).

And nobody ever sold you could do the same thing with C++.

*BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.

The "this(Arg arg = someDefault)" is a flagrant example of something that should be rejected. Not only because it's stupid to write in plain D, but also because it creates gratuitous deviation from the behavior you'd get in C++. And that's actually very bad (IMO).

"monarch_dodra"  wrote in message news:rftskgfoeuvyeuvrusei@forum.dlang.org...

> *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.

These expectations will lead to disappointment. 

On Thursday, 10 April 2014 at 21:23:43 UTC, monarch_dodra wrote:>
> *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.

It does not work that way and has never worked. Think about class semantics for example.

On Friday, 11 April 2014 at 12:58:09 UTC, Dicebot wrote:
> On Thursday, 10 April 2014 at 21:23:43 UTC, monarch_dodra wrote:>
>> *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.
>
> It does not work that way and has never worked. Think about class semantics for example.

Yeah. It'd say those wouldn't compile anyway, but I guess something as trivial as:
//----
class A
{...}
A a;
a.doit;
//----
Would compile for both languages, but give different results.

Fine.

On Friday, April 11, 2014 22:38:28 Daniel Murphy wrote:
> "monarch_dodra"  wrote in message news:rftskgfoeuvyeuvrusei@forum.dlang.org...
> 
> > *BUT*, if you happen to copy paste C++ code, and it *does* compile, then it is pretty much expected to keep the same resulting semantics, yes.
> 
> These expectations will lead to disappointment.

One of the goals of D was to make it so that when _C_ code was compiled as D code, it either wouldn't compile or would have identical semantics, and I believe that that is still true save for a very short list of exceptions (the only ones that come to mind are that the calling conventions wouldn't be the same and that static arrays are value types in D whereas they're reference types in C).

However, that's not at all true for C++. You're probably more likely to be able to port Java code directly and have it have the same semantics than C++ code. A shining example of that is the semantics for variables of class types. In C++, if they're not declared as pointers, then they're value types, whereas they're always reference types in D.

Part of the whole point of D is to have better semantics than C++, so it's certainly not going to try and keep the same semantics as C++. For the most part, we haven't gratuitously changed the semantics, but there are a lot of places where we gained something by changing them, so we did.

- Jonathan M Davis

On 2014-04-11 15:53, monarch_dodra wrote:

> Yeah. It'd say those wouldn't compile anyway, but I guess something as
> trivial as:
> //----
> class A
> {...}
> A a;
> a.doit;
> //----
> Would compile for both languages, but give different results.
>
> Fine.

Unless "doit" is non-virtual in both versions.

-- 
/Jacob Carlborg