On Tuesday, 31 October 2017 at 02:24:48 UTC, Steven Schveighoffer
wrote:
Yeah... my problem is, that I don't know it at compile time.
You know it at language time :)
:)
The .init property is provided by the compiler, unless you
define it. It means the default value of the type.
Here, I'm t
On 10/30/17 11:39 AM, Alex wrote:
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer wrote:
This should also be disallowed. In order to know x.init means what it
normally means, we shouldn't allow overriding it. This is the point of
this thread, and the impetus for renaming of T
On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer
wrote:
This should also be disallowed. In order to know x.init means
what it normally means, we shouldn't allow overriding it. This
is the point of this thread, and the impetus for renaming of
TypeInfo.init().
Yeah... my prob
On 10/30/17 6:59 AM, Alex wrote:
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should not be
overridden. Bu
Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should
not be overridden. But how about to override it with a
On Friday, 26 August 2016 at 15:14:42 UTC, Steven Schveighoffer
wrote:
FYI, you cannot make this patch until we fully deprecate the
use of TypeInfo.init:
https://github.com/dlang/druntime/blob/master/src/object.d#L294
So at least until 2.075.
-Steve
Ah yes, good thinking. I'll keep that in
On 8/26/16 6:52 AM, Cauterite wrote:
On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote:
And I expect that it will become an error at some point in the future
to define an init member for a user-defined type, at which point,
there won't be any choice about fixing it.
I might tak
On Friday, August 26, 2016 10:52:47 Cauterite via Digitalmars-d-learn wrote:
> On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote:
> > And I expect that it will become an error at some point in the
> > future to define an init member for a user-defined type, at
> > which point, there
On Friday, August 26, 2016 11:20:56 Johan Engelen via Digitalmars-d-learn
wrote:
> On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote:
> > You're supposed to be able to depend on .init existing. Default
> > initialization for structs can be disabled via
> >
> > @disable this();
> >
On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote:
You're supposed to be able to depend on .init existing. Default
initialization for structs can be disabled via
@disable this();
but even then, the init member still exists (it just isn't used
for default initialization).
F
On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote:
And I expect that it will become an error at some point in the
future to define an init member for a user-defined type, at
which point, there won't be any choice about fixing it.
I might take a crack at this patch. Sounds prett
On Friday, August 26, 2016 08:59:55 Cauterite via Digitalmars-d-learn wrote:
> How can I get the initial value of an arbitrary type? Since any
> struct can override it, .init is not reliable:
>
> struct Z {
> enum init = 6;
> string val = `asdf`;
> };
> assert(Z.init == 6);
> assert(typeof(Z())
12 matches
Mail list logo
