People, why you hates ctors for structs ?
Default ctor - simple a workaround.
Just allow ctors with structs and it's all.
On Thursday, 10 April 2014 at 11:13:45 UTC, monarch_dodra wrote:
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 =
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
E.g. it could look like this (alternative a new keyword
explicit could be introduced, but introduction of new
keywords is usually avoided if possible, AFAIK):
sorry for not reading the whole post and necroposting, but
please,
On 2014-04-11 22:48, monarch_dodra wrote:
Right, the call will succeed, but if the function accesses any class
members, it will access violation *there*. Hence the highly likely.
Yeah, right.
--
/Jacob Carlborg
monarch_dodra wrote in message
news:rftskgfoeuvyeuvru...@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
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
On Friday, April 11, 2014 22:38:28 Daniel Murphy wrote:
monarch_dodra wrote in message
news:rftskgfoeuvyeuvru...@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
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
On Friday, 11 April 2014 at 15:54:36 UTC, Jacob Carlborg wrote:
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.
monarch_dodra wrote in message
news:ktbdlcaqahsqmwkid...@forum.dlang.org...
Why? The D version would just go from object.Error Access Violation to
AssertError null this.
And in release, you'd still (highly probably) still get the Access
Violation.
Sadly I've encountered C++ code that
On Friday, 11 April 2014 at 12:38:14 UTC, Daniel Murphy wrote:
monarch_dodra wrote in message
news:rftskgfoeuvyeuvru...@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
On Friday, April 11, 2014 17:00:50 Remo wrote:
On Friday, 11 April 2014 at 12:38:14 UTC, Daniel Murphy wrote:
monarch_dodra wrote in message
news:rftskgfoeuvyeuvru...@forum.dlang.org...
*BUT*, if you happen to copy paste C++ code, and it *does*
compile, then it is pretty much expected
On 2014-04-11 18:05, monarch_dodra wrote:
Why? The D version would just go from object.Error Access Violation to
AssertError null this.
Hmm, I was pretty sure it wouldn't assert.
And in release, you'd still (highly probably) still get the Access
Violation.
No, in release mode it's
On Friday, 11 April 2014 at 20:36:12 UTC, Jacob Carlborg wrote:
On 2014-04-11 18:05, monarch_dodra wrote:
Why? The D version would just go from object.Error Access
Violation to
AssertError null this.
Hmm, I was pretty sure it wouldn't assert.
And in release, you'd still (highly probably)
On Saturday, April 12, 2014 02:26:54 Daniel Murphy wrote:
monarch_dodra wrote in message
news:ktbdlcaqahsqmwkid...@forum.dlang.org...
Why? The D version would just go from object.Error Access Violation to
AssertError null this.
And in release, you'd still (highly probably) still get
On Wednesday, 9 April 2014 at 18:41:57 UTC, Walter Bright wrote:
On 4/9/2014 7:59 AM, Benjamin Thaut wrote:
What do you think? CC welcome.
Or you could use a factory function:
struct Foo {
static Foo factory() { ... }
...
}
auto foo = Foo.factory();
Yeah. For sure.
Or a
On 4/9/14, Brian Schott briancsch...@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
On Thursday, 10 April 2014 at 11:39:16 UTC, Andrej Mitrovic wrote:
On 4/9/14, Brian Schott briancsch...@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;
+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:
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
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.
Just to be clear, I don't want a default constructor for structs that
gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword explicit could be
introduced, but introduction
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
Just to be clear, I don't want a default constructor for
structs that gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default
constructor. E.g. it could look like this
On Wednesday, 9 April 2014 at 14:59:35 UTC, Benjamin Thaut wrote:
What do you think? CC welcome.
Kind Regards
Benjamin Thaut
I haven't read though the entire proposal yet (sorry!), but I'm
in definite agreement that *something* needs to be done to allow
explicit but argument-less
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
On 2014-04-09 16:59, Benjamin Thaut wrote:
Just to be clear, I don't want a default constructor for structs that
gets called implictly by the compiler, like in C++.
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword
On Wednesday, 9 April 2014 at 17:07:13 UTC, Jacob Carlborg wrote:
Result in an ambiguity error?
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;
On 2014-04-09 18:59, Brian Schott wrote:
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
Result in an ambiguity error?
--
/Jacob Carlborg
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Instead I would really love to have a explicit default constructor. E.g.
it could look like this (alternative a new keyword explicit could be
introduced, but introduction of new keywords is usually avoided if
possible, AFAIK):
struct Foo
{
On 4/9/2014 7:59 AM, Benjamin Thaut wrote:
What do you think? CC welcome.
Or you could use a factory function:
struct Foo {
static Foo factory() { ... }
...
}
auto foo = Foo.factory();
Am 09.04.2014 18:59, schrieb Brian Schott:
What would this do?
struct SomeStruct
{
this(int i = 10)
{
this.i = i;
}
this(void)
{
this.i = 20;
}
int i;
}
auto s = SomeStruct();
Thats easy to answer. What would it do if you replace the
Am 09.04.2014 19:05, schrieb Jacob Carlborg:
What's the advantage over using a static opCall, that it works with new?
That you can use it together with @disable this();
Am 09.04.2014 20:42, schrieb Walter Bright:
On 4/9/2014 7:59 AM, Benjamin Thaut wrote:
What do you think? CC welcome.
Or you could use a factory function:
struct Foo {
static Foo factory() { ... }
...
}
auto foo = Foo.factory();
But I don't want the construction to
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut wrote:
Thats easy to answer. What would it do if you replace the
struct with class and the void with nothing?
This thread is giving me some fun ideas for static analysis rules.
Am 09.04.2014 20:53, schrieb Brian Schott:
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut wrote:
Thats easy to answer. What would it do if you replace the struct
with class and the void with nothing?
This thread is giving me some fun ideas for static analysis rules.
Just saying,
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no init value
auto foo2=Foo(); // ok
}
Because then the user might think, that the
On 04/09/2014 08:53 PM, Benjamin Thaut wrote:
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no init value
auto foo2=Foo(); // ok
}
On Wednesday, 9 April 2014 at 18:53:20 UTC, Brian Schott wrote:
On Wednesday, 9 April 2014 at 18:47:41 UTC, Benjamin Thaut
wrote:
Thats easy to answer. What would it do if you replace the
struct with class and the void with nothing?
This thread is giving me some fun ideas for static analysis
Am 09.04.2014 21:02, schrieb Timon Gehr:
On 04/09/2014 08:53 PM, Benjamin Thaut wrote:
Am 09.04.2014 20:33, schrieb Timon Gehr:
On 04/09/2014 04:59 PM, Benjamin Thaut wrote:
Why not just:
struct Foo{
this(){
// do stuff here
}
}
void main(){
Foo foo1; // error, no
On 2014-04-09 19:10, Brian Schott 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 =
41 matches
Mail list logo
