On Wednesday, 11 July 2018 at 16:58:53 UTC, Greatsam4sure wrote:
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
[...]
Every language is plague with one bug or the order. For those
will great love for the language they lend a helping hand to
fixed the bug. I expect you to
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
On Tuesday, 10 July 2018 at 21:08:32 UTC, Cym13 wrote:
First of all I must point that I would very much like to have
seen a code actually producing an error in that article.
Contrary to what is hinted just taking the struct and
On Wednesday, 11 July 2018 at 16:54:18 UTC, Greatsam4sure wrote:
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
[...]
Sincerely speaking D language does not merit all these
criticism. The magnitude of criticism on D language does not
really make sense to me. I am yet to
On Monday, 23 July 2018 at 14:26:17 UTC, Nick Treleaven wrote:
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature
wrote:
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
I implemented the compile time format string checking by
evaluating
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
I implemented the compile time format string checking by
evaluating `format(fmtStr, Args.init)` at compile time and seeing
if an
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
That would work, it's just a really horrible hack and I hate it.
Bastiaan's solution to simply change the default value slipped my
mind but is really cleaner and in the same line of thought.
We're constructing a fictitious
the following seems like a easy enough workaround:
just add
` if(this is typeof(this).init) return;` at 1st line of your invariant:
```d
import std.typecons;
import std.range;
struct MyDomainData {
string username;
this(string username) @safe
in(!username.empty)
do {
On Wednesday, 11 July 2018 at 03:00:48 UTC, Ali wrote:
Somehow, this is the type of problem, i thought point 1 in the
vision document is aimed to solve
https://wiki.dlang.org/Vision/2018H1
"1. Lock down the language definition: D is a powerful language
but its definition is not precise
On Wednesday, 11 July 2018 at 20:10:17 UTC, Meta wrote:
I hate to say I told you so, but...
https://github.com/dlang/phobos/pull/5855#issuecomment-345783238
Just joking, of course =)
Nullable has needed to be completely overhauled for a long time
because it was only really designed with POD
On Wednesday, 11 July 2018 at 07:35:24 UTC, FeepingCreature wrote:
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature
wrote:
Then just stick it in a Nullable. No explicit .init needed.
To clarify this point some more, since on reflection it's
ambiguous: you might well say that "well
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594
On Tuesday, 10 July 2018 at 15:10:21 UTC, Dukc wrote:
It definitely needs clarification if I understood it's intent
right.
https://github.com/dlang/dlang.org/pull/2418
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
Then just stick it in a Nullable. No explicit .init needed.
To clarify this point some more, since on reflection it's
ambiguous: you might well say that "well yeah, the default
constructor returns an invalid value, no shit it
On Tuesday, 10 July 2018 at 21:08:32 UTC, Cym13 wrote:
First of all I must point that I would very much like to have
seen a code actually producing an error in that article.
Contrary to what is hinted just taking the struct and putting
using it with Nullable or format() caused no error for me
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Somehow, this is the type of problem, i thought point 1
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Have you tried giving your invariants a valid initial
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
It is not very enthusiastic.
https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43
Related links:
https://github.com/dlang/phobos/pull/6594
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote:
I've written up a short blogpost about the T.init issue.
I believe that whoever wrote that spec meant that the invariant
WOULD not need to hold if MyDomainData.init WAS called, but that
MyDomainData.init must not be called if
20 matches
Mail list logo
