On 10/10/2014 22:19, monarch_dodra wrote:
Think the argument is that declaring `T t;` must be CTFE, which kind of
implies a T.init state (which may have non-deterministic values in the
presence of " = void").
This is mostly for declaring things static, and the whole "constructors
are run after t
On Saturday, 11 October 2014 at 09:19:47 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 11 Oct 2014 08:53:08 +
dcrepid via Digitalmars-d wrote:
structs also can't be inherited and can't have virtual methods
(obviously, as they have no VMT). just a comment. ;-)
Yeah, thats one of the things
On Sat, 11 Oct 2014 08:53:08 +
dcrepid via Digitalmars-d wrote:
structs also can't be inherited and can't have virtual methods
(obviously, as they have no VMT). just a comment. ;-)
ah, and don't forget another great aspect of structs: confusing C++
users! ;-)
signature.asc
Description: PGP
On Sat, 11 Oct 2014 08:41:15 +
Nicolas Sicard via Digitalmars-d wrote:
> On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
> Digitalmars-d wrote:
> >> I think I like the idea of the factory method now though, as
> >> I've learned you can hide a struct inside a function, and then
> >> c
Okay, I'm still kind of new to this language, so forgive me if I
see things a little differently than long time users..
Here's what I see though.
With Walter's description of what structures should be, it seems
to me to be slightly at odds with what D structures are capable
of, and in fact wh
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 21:45:32 +
Shouldn't properties not mutate the data?
it depends. ;-) i think that doing such "lazy initialization" in
property is acceptable. maybe not the best style, but
acceptable. yet i
may
On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
I think I like the idea of the factory method now though, as
I've learned you can hide a struct inside a function, and then
call the function to set the struct up properly and return it.
At least, I'm sure I've seen cod
On Friday, October 10, 2014 22:49:13 Walter Bright via Digitalmars-d wrote:
> On 10/10/2014 9:43 PM, Dicebot wrote:
> > There is ER somewhere in bugzilla AFAIR about allowing CTFE-only struct
> > default constructors.
>
> Note that you can do (as pointed out upthread):
>
> struct S {
>
On 10/10/2014 9:43 PM, Dicebot wrote:
On Saturday, 11 October 2014 at 04:41:52 UTC, Walter Bright wrote:
On 10/10/2014 5:25 PM, Simon A wrote:
D has native functional purity. Couldn't you get the same
benefits that you listed by allowing default constructors but
requiring them to be pure?
I
On Saturday, 11 October 2014 at 04:41:52 UTC, Walter Bright wrote:
On 10/10/2014 5:25 PM, Simon A wrote:
D has native functional purity. Couldn't you get the same
benefits that you listed by allowing default constructors but
requiring them to be pure?
I suspect that CTFE can accomplish most o
On 10/10/2014 5:25 PM, Simon A wrote:
D has native functional purity. Couldn't you get the same
benefits that you listed by allowing default constructors but
requiring them to be pure?
I suspect that CTFE can accomplish most of that today - with the exception that
CTFE will not allocate runti
On Friday, 10 October 2014 at 09:14:16 UTC, Marc Schütz wrote:
You can use `static opCall` as a workaround.
Please don't. It is never worth the gain. Never.
On Friday, 10 October 2014 at 09:58:54 UTC, Walter Bright wrote:
On 11/27/2011 11:53 AM, deadalnix wrote:
I wonder why struct can't have a default constructor. TDPL
state that it is
required to allow every types to have a constant .init .
Having a .init instead of a default constructor has al
On Fri, 10 Oct 2014 21:45:32 +
dcrepid via Digitalmars-d wrote:
> Great, thanks for the tips!
you're welcome. ;-)
> Thanks for the effort of providing a proof of concept, even
> though I don't agree with what the data property should do.
> Shouldn't properties not mutate the data?
it depen
On Friday, 10 October 2014 at 20:25:16 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 18:50:29 +
dcrepid via Digitalmars-d wrote:
What I mean with the scoped objects is that you still need to
provide a constructor with parameters, yes? I will have to try
this out myself, but I'v
On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
Hi,
I wonder why struct can't have a default constructor. TDPL
state that it is required to allow every types to have a
constant .init .
That is true, however not suffiscient. A struct can has a
void[constant] as a member and thi
On Fri, 10 Oct 2014 18:50:29 +
dcrepid via Digitalmars-d wrote:
> What I mean with the scoped objects is that you still need to
> provide a constructor with parameters, yes? I will have to try
> this out myself, but I've avoided it since some people seem to
> indicate this is going to be d
On Friday, 10 October 2014 at 08:03:49 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 01:32:51 +
dcrepid via Digitalmars-d wrote:
So no possibility of using objects as resource acquire/release
mechanisms.
I assume using scoped with class objects will have a similar
problem..
no,
On 10/10/2014 3:23 AM, Szymon Gatner wrote:
Bit OT: What is The D code style then? It would be very useful for those coming
from C++ to have a wiki/article on how to translate C++ idioms and practices to
D. I too am writing D code like I do my C++ and often find myself puzzled
(deterministic d-to
On 10/10/2014 3:25 AM, ketmar via Digitalmars-d wrote:
people also keep forgetting about default values and want
default constructors to simulate this:
struct {
int n = 42;
string s = "default string";
}
That's a good observation.
On Friday, 10 October 2014 at 09:58:54 UTC, Walter Bright wrote:
On 11/27/2011 11:53 AM, deadalnix wrote:
I wonder why struct can't have a default constructor. TDPL
state that it is
required to allow every types to have a constant .init .
Having a .init instead of a default constructor has al
On Fri, 10 Oct 2014 02:58:39 -0700
Walter Bright via Digitalmars-d wrote:
> Default constructors are baked into C++. I can't escape the
> impression that the desire for D default constructors comes from more
> or less trying to write C++ style code in D.
second this. people also keep forgetting a
On 11/27/2011 11:53 AM, deadalnix wrote:
I wonder why struct can't have a default constructor. TDPL state that it is
required to allow every types to have a constant .init .
Having a .init instead of a default constructor has all kinds of useful
properties:
1. the default object is trivially
On Friday, 10 October 2014 at 01:32:54 UTC, dcrepid wrote:
On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
Hi,
I wonder why struct can't have a default constructor...
I know this is an old thread, but I've run into this same
problem recently and search yielded this result.
I
On Fri, 10 Oct 2014 01:32:51 +
dcrepid via Digitalmars-d wrote:
> This seems like a language limitation to me.
that is what we have to pay for the rule "type must always has
well-defined initial value".
the thing is that struct must have initial value that can be calculated
without executing
On Sunday, 27 November 2011 at 19:50:24 UTC, deadalnix wrote:
Hi,
I wonder why struct can't have a default constructor...
I know this is an old thread, but I've run into this same problem
recently and search yielded this result.
I myself have tried working around the default-constructor
pr
On Sun, 27 Nov 2011 21:39:05 +0100, Andrej Mitrovic wrote:
> That's not a workaround, that ctor never gets called unless you pass an
> argument.
But it lets you pass a Range test.
Le 27/11/2011 22:24, Simen Kjærås a écrit :
On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix wrote:
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the
On Sun, 27 Nov 2011 21:19:38 +0100, deadalnix wrote:
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the language.
I believe your "workaround" will
Le 27/11/2011 21:39, Andrej Mitrovic a écrit :
That's not a workaround, that ctor never gets called unless you pass
an argument.
So if you @disable this(); you shouldn't get an error. Actually, you
have an implicit constructor, even if it's only to set the variable as
equal to .init property
Wait nevermind, I thought you mean't the ctor *actually runs*. What
you meant was disable this() doesn't work with that ctor in place.
On 11/27/11, Andrej Mitrovic wrote:
> That's not a workaround, that ctor never gets called unless you pass
> an argument.
>
That's not a workaround, that ctor never gets called unless you pass
an argument.
In addition, here is a workaround :
// Wonderfull !
@disable this();
// Default constructor workaround.
this(int dummy = 0) { ... }
But that look very dirty and it feels like working against the language.
33 matches
Mail list logo
