Re: We have completed our GSoC 2013 application

[Timothee Cour]

I'm still willing to mentor, whether under G or D Soc!

On Tue, Apr 9, 2013 at 12:10 AM, Walter Bright
 wrote:
> On 4/8/2013 11:42 PM, Rory McGuire wrote:
>>
>> Could we not still run the basics of the program minus the funding?
>> Perhaps
>> there are still students and mentors that would be interested
>> in contributing their time for their name down in the history of D. :)
>>
>> We could call it DSoC. There would still be an approval process that way
>> everyone knows what is expected and there is still the experience
>> and record of that experience for potential employers to refer to so that
>> candidates can use the experience for reference.
>>
>> The D community is stable so I really think this could work (as opposed to
>> a
>> unstable community where references would mean nothing).
>> I would be interested in DSoC more than GSoC because I work full-time and
>> wouldn't be able to put in a full summer of time.
>
>
> Very interesting idea!
>

Re: dip - another D package manager

[Timothee Cour]

great! Can you explain a bit pros/cons wrt other ones such as dub?
also, dip name is a bit confusing because DIP stands for D Improvement
Proposal, wiki.dlang.org/DIPs.

On Fri, May 17, 2013 at 3:53 PM, Rory McGuire  wrote:

> Hi all,
>
> I've started working on a little experimental package manager
> https://github.com/rjmcguire/dip that works similar to golang's go
> command.
> I've only tested it on linux amd64.
>
> At the moment the commands that work are (these are examples):
>
> # to fetch a repo using git (only works for github.com at the mo'), files
> placed in $DPATH[0]/src/
> dip get github.com/D-Programming-Deimos/openssl
>
> # to build
> dip github.com/D-Programming-Deimos/openssl
> # or from a packages directory:
> dip
>
> # to install in the first path found in DPATH, $DPATH[0]/bin for
> executables:
> dip -i
> # or
> dip install github.com/D-Programming-Deimos/openssl
>
> Program expects a environment variable DPATH to exist, it will tell you:
> *$ dip*
> *WARNING DPATH NOT SET, suggest DPATH="~/d/:/usr/local/d"*
>
> Program assumes dmd is in /usr/local/d/bin/dmd unless you set DROOT to
> something else such as "/usr/" in which case it will use /usr/bin/dmd.
>
> Config is in README.md example (excluding == lines):
> =
> # vibe.d - The vibe.d web services framework
>
> ## Dependencies:
>  * github.com/D-Programming-Deimos/openssl: >=0
>  * github.com/D-Programming-Deimos/libevent: >=0
>
> ## Flags:
>  * Library
>  * -version=VibeLibeventDriver - options are VibeLibevDriver,
> VibeLibeventDriver
> =
>
>
> todo:
> * handle dub packages, their dependencies are not fully qualified in
> package.json so I can't just load them from the file, if you put qualified
> dependencies in "dip-dependencies" in package.json it does work.
> * support sourceforge etc...
> * most likely I'll be changing the way config works because it doesn't
> look nice in github's md viewer.
> * check versions of packages and enforce them
> * output help
> * Fix bugs :)
>
> Thanks.
>
> Kind regards,
>
>

Re: dmd 2.063 beta 5

[Timothee Cour]

just filed a regression from 062 to 063:
http://d.puremagic.com/issues/show_bug.cgi?id=10141
it only affects error message though (giving a nonsensical error message).

Digression:
I used dustmite to reduce it (awesome tool) down to 6 files, but then had
to further manually reduce to 1 file.
I wish dustmite could be improved to 'run the last mile' by attempting to
merge files:
a.d:
import b;
b.d:
import c;
c.d:
//some stuff

dustmite should attempt to merge such files and reduce to:
a.d
// some stuff




On Tue, May 21, 2013 at 1:36 PM, Walter Bright
wrote:

>
> Join the dmd beta mailing list to keep up with the betas. This one is
> pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/**dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/**buglist.cgi?query_format=**
> advanced&bug_severity=**regression&bug_status=NEW&bug_**
> status=ASSIGNED&bug_status=**REOPENED
>

Re: dmd 2.063 beta 5

[Timothee Cour]

and another regression, this time more serious, that came up in my code:

http://d.puremagic.com/issues/show_bug.cgi?id=10148

Note, dustmite got stuck forever trying to reduce it, so i had to reduce
manually.


On Tue, May 21, 2013 at 1:36 PM, Walter Bright
wrote:

>
> Join the dmd beta mailing list to keep up with the betas. This one is
> pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/**dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/**buglist.cgi?query_format=**
> advanced&bug_severity=**regression&bug_status=NEW&bug_**
> status=ASSIGNED&bug_status=**REOPENED
>

Re: Mono-D 0.5.4.1 - Build, completion & other fixes + Unittests via rdmd

[Timothee Cour]

On Wed, Oct 16, 2013 at 2:21 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:

> On 10/16/13 5:38 AM, Bruno Medeiros wrote:
>
>> On 08/10/2013 14:18, Alexander Bothe wrote:
>>
>>> Are there any plans/tricks/hacks on how to get programs built
>>> with dmd debuggable with gdb? Then we also could release the
>>> addin for Windows as well!
>>> (Afaik I asked the same question some time ago, but well, perhaps
>>> something did change over the time :-))
>>>
>>
>> I was wondering the same as well... But from the lack of answers I think
>> not much can be done? :/
>>
>
> What are the matters involved? I did get basic debugging sessions working,
> but I forgot whether it was dmd or gdc.
>
> Andrei
>
>
on OSX, lldb has better support than gdb.

Re: early alpha of D REPL

[Timothee Cour]

already added a bug report in github for that


On Wed, Feb 12, 2014 at 11:56 AM, MattCoder
wrote:

> On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
>
>> Barely running but already fun and a little useful.
>>
>
> Interesting!
>
> I was playing around:
>
> D> write("test");
> => undefined identifier write
> D> import std.stdio;
> => std
> D> write("test");
> D>
>
> Shouldn't code above print "test"?
>

Re: DMD v2.066.0-rc1

[Timothee Cour via Digitalmars-d-announce]

On Thu, Aug 7, 2014 at 11:11 AM, Jonathan M Davis via
Digitalmars-d-announce  wrote:

> On Thursday, 7 August 2014 at 17:05:29 UTC, Manu via
> Digitalmars-d-announce wrote:
>
>> I've never encountered anybody try and use MSC from the command line in
>> about 15 years professionally.
>>
>
> LOL. That's almost always how I use VS when I'm forced to use it at work.
> As soon as I figured out that I could build from the command line using VS,
> I stopped opening it unless I had to in order to run the debugger.
>
> But I'm not even vaguely a typical Windows developer. I'm pretty hardcore
> Linux, all things considered.
>
> - Jonathan M Davis
>

Likewise, when I had to use windows and VS (for visualD+other stuff),
running from command line was the only way I could find to execute my
scripts, set appropriate environment variables etc, without having to spend
time every time something changed clicking through options (which is
terrible in most IDEs including VS). Command line saves time every time you
have to do a task more than once, administer different machines etc.

Re: New D book available for pre-order: D Web Development

[Timothee Cour via Digitalmars-d-announce]

is there a url to download the code samples mentioned in the ebook?

On Sun, Jan 31, 2016 at 5:08 AM, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 2016-01-30 19:09, barberian wrote:
>
> I don't know what you're seeing there, but here:
>>
>> Ebook = 25,18 (pounds)
>> Ebook + Physical = 25,99 (pounds)
>>
>> So for what I understand if you by the Physical copy you win the ebook.
>>
>
> Ebook = €36.23
> Ebook + physical = €35.99
>
> --
> /Jacob Carlborg
>

Re: New D book available for pre-order: D Web Development

[Timothee Cour via Digitalmars-d-announce]

found it under https://www.packtpub.com/web-development/d-web-development


On Sat, Feb 6, 2016 at 12:50 AM, Timothee Cour 
wrote:

> is there a url to download the code samples mentioned in the ebook?
>
> On Sun, Jan 31, 2016 at 5:08 AM, Jacob Carlborg via Digitalmars-d-announce
>  wrote:
>
>> On 2016-01-30 19:09, barberian wrote:
>>
>> I don't know what you're seeing there, but here:
>>>
>>> Ebook = 25,18 (pounds)
>>> Ebook + Physical = 25,99 (pounds)
>>>
>>> So for what I understand if you by the Physical copy you win the ebook.
>>>
>>
>> Ebook = €36.23
>> Ebook + physical = €35.99
>>
>> --
>> /Jacob Carlborg
>>
>
>

Re: Silicon Valley D Meetup June 23, 2016 - Jason White's Button and other topics

[Timothee Cour via Digitalmars-d-announce]

no sound :(

On Thu, Jun 23, 2016 at 7:18 PM, Ali Çehreli <
digitalmars-d-announce@puremagic.com> wrote:

> Google Hangout:
>
>
>
> https://hangouts.google.com/hangouts/_/hoaevent/AP36tYciptM-tYpkf-Y0NXXs__5mWY5fBGv_x7TA25cYLo3TZPIe3w?hl=en&authuser=1
>
> Ali
>
>
> On 06/23/2016 01:45 PM, Ali Çehreli wrote:
>
>> Sorry for short notice but we're meeting at 7pm California time:
>>
>>http://www.meetup.com/D-Lang-Silicon-Valley/events/231917495/
>>
>> Among other topics, Jason White will introduce Button, his build system:
>>
>>http://forum.dlang.org/thread/uhozcvatvyztfuhiv...@forum.dlang.org
>>
>> Don't expect a proper presentation as he had very short notice as well;
>> it will be more like a fireside chat. :) (Note: Jason will be able to
>> connect at around 8pm.)
>>
>> I will post Google Hangouts link here at the start of the meetup.
>>
>> Ali
>>
>
>

Re: Many documentation examples can now be run online

[Timothee Cour via Digitalmars-d-announce]

is it properly sandboxed / hacking proof?

quick tests:

```
import std.process;
auto msg="sleep 10";
executeShell(msg).output.writeln;
```

 correctly results in `Application output (9: Killed)`

"ls -al .."  => permission denied

"ls /usr/bin/ld" => -rwxr-xr-x 2 0 0 834648 Jan  3  2013 /usr/bin/ld

"ps -auwx" => ...



On Mon, Dec 19, 2016 at 6:25 PM, Joakim via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Monday, 19 December 2016 at 17:50:17 UTC, Seb wrote:
>
>> On Monday, 19 December 2016 at 17:44:29 UTC, Andrei Alexandrescu wrote:
>>
>>> Take a look e.g. at https://dlang.org/phobos-prere
>>> lease/std_algorithm_iteration.html. Examples now have "Edit" and "Run"
>>> buttons that allow you to play with them online and see what they output.
>>> Changes for the ddox version forthcoming.
>>>
>>> Related: https://github.com/dlang/dlang.org/pull/1297,
>>> https://issues.dlang.org/show_bug.cgi?id=16984,
>>> https://issues.dlang.org/show_bug.cgi?id=16985.
>>>
>>> Many thanks to Sebastian Wilzbach who took this to completion, and to
>>> Damian Ziemba for working on the online compiler code!
>>>
>>>
>>> Andrei
>>>
>>
>> I would like to add that this is in an experimental/testing stage and
>> hopefully will get stable with the next release ;-)
>>
>
> When all tests pass, would be better if it said that, rather than "No
> output," which it says now.
>

Re: Beta 2.073.0-b1

[Timothee Cour via Digitalmars-d-announce]

* -transition=safe/-dip1000
=> not mentioned in http://dlang.org/changelog/2.073.0.html

* std.experimental.ndslice has been deprecated. The synchronization between
Phobos and Mir turned out to be a lot of work with litte gain

=> That's a good move. Will make development faster indeed by not being
tied to dmd releases. The downside of `batteries included` is is hampers
development speed, deprecation speed, etc. Another example: std.json sucks
compared to http://vibed.org/api/vibe.data.json/



On Sat, Jan 7, 2017 at 8:49 AM, biozic via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Saturday, 7 January 2017 at 15:59:47 UTC, Martin Nowak wrote:
>
>> On 01/07/2017 03:44 PM, biozic wrote:
>>
>>> Are phobos unittests not passing when compiling with -dip1000 considered
>>> bugs or is it this experimental?
>>>
>>
>> Most of phobos is currently not usable with DIP1000, partly because
>> safety checks are hard errors (instead of deprecations) and partly
>> because of implementation bugs.
>> You can try it experimentally with isolated code snippets.
>> Don't expect much documentation or help at this stage, the feature will
>> properly released when it's finished.
>>
>> Any way to escape pointers in @safe code with -dip1000 enabled are
>> considered bugs and should be reported under issues.dlang.org using the
>> `safe` keyword and `[scope]` in the title.
>>
>> https://issues.dlang.org/buglist.cgi?keywords=safe&keywords_
>> type=allwords&query_format=advanced&resolution=---&short_
>> desc=%5Bscope%5D&short_desc_type=substring
>>
>> -Martin
>>
>
> Thanks for the precisions!
>

Re: Beta 2.073.0-b1

[Timothee Cour via Digitalmars-d-announce]

>
> * -transition=safe/-dip1000
> => not mentioned in http://dlang.org/changelog/2.073.0.html
>

> That's deliberate, as you can't even use it with writeln yet.

https://issues.dlang.org/show_bug.cgi?id=17090 `dmd -transition=?` needs
quoting => make it `-transition=help`

On Sat, Jan 14, 2017 at 3:46 AM, Walter Bright via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 1/7/2017 3:54 AM, Jacob Carlborg wrote:
>
>> On 2017-01-07 06:02, Martin Nowak wrote:
>>
>>> an experimental safety checks (-transition=safe/-dip1000)
>>>
>> Is the flag to enable the new checks or revert to the previous behavior?
>>
>
> enable
>

Re: LDC 1.7.0-beta1

[Timothee Cour via Digitalmars-d-announce]

could these releases be tied to 'homebrew/linuxbrew' upgrades as part
of release process?


On Sun, Dec 10, 2017 at 10:11 AM, Suliman via Digitalmars-d-announce
 wrote:
> On Sunday, 10 December 2017 at 17:33:34 UTC, kinke wrote:
>>
>> Hi everyone,
>>
>> on behalf of the LDC team, I'm glad to announce the first beta for LDC
>> 1.7. The highlights of this version in a nutshell:
>>
>> * Based on D 2.077.1.
>> * Catching C++ exceptions supported on Linux and Windows.
>>
>> Full release log and downloads:
>> https://github.com/ldc-developers/ldc/releases/tag/v1.7.0-beta1
>>
>> Thanks to all contributors!
>
>
> Is it's possible to produce x64 binaries on Windows x64 without installing
> Visual Studio? DMD do not have linker for x64.

Re: Released vibe.d 0.8.2

[Timothee Cour via Digitalmars-d-announce]

that's great... unfortunately
https://github.com/vibe-d/vibe.d/issues/1991 is a regression
preventing from updating to 0.8.X (has a reduced test case). Any help
on this would be very appreciated, thanks!

On Tue, Dec 12, 2017 at 11:44 AM, Sönke Ludwig via
Digitalmars-d-announce  wrote:
> The major changes in this release are HTTP forward proxy support, handling
> incoming HTTP requests on custom transports and a MongoDB based session
> store. On top of that, there are many smaller improvements in the HTTP
> server, web/REST generator, JSON/BSON support and the TLS sub system.
>
> Change log:
> https://vibed.org/blog/posts/vibe-release-0.8.2
>
> DUB package:
> https://code.dlang.org/packages/vibe-d/0.8.2

Re: Beta 2.078.2

[Timothee Cour via Digitalmars-d-announce]

thanks @aG0aep6G for this PR https://github.com/dlang/dmd/pull/7841 to fix it.
this should be in point release because:
* ldc2 has correct behavior
* the bug disappears with `-O`
so the argument that ppl would rely on it is moot


On Fri, Feb 2, 2018 at 6:37 AM, Steven Schveighoffer via
Digitalmars-d-announce  wrote:
> On 2/2/18 4:29 AM, Seb wrote:
>>
>> On Friday, 2 February 2018 at 08:34:32 UTC, Antonio Corbi wrote:
>
>
>>> Wouldn't it be good to include a fix for errors like produced by int.min
>>> assigned to a variable
>>> (https://forum.dlang.org/post/p4l7kt$80d$1...@digitalmars.com) in a point
>>> release like this?
>>
>>
>> No, while I understand that you would like this to be fixed, this change
>> might be disruptive - you never know on what weird behavior people rely.
>> Anything potentially breaking existing code can't be part of a patch
>> release.
>
>
> In some cases, yes, we need to have a deprecation period as people may
> depend on the behavior.
>
> In this case, however, the codegen is simply wrong. It can be fixed
> immediately. I would hazard to guess that nobody is depending on int.min
> being greater than 0.
>
>> Also AFAICT no one has submitted a PR to fix the issue you referenced, so
>> it's a hypothetical question (for now).
>
>
> I would suggest to would-be fixers, just do the correct thing that may be
> less performant, and we can worry about optimizing later (and add a unit
> test of course!). There is nothing worse than a compiler that doesn't emit
> the code you expect it to.
>
> -Steve

Re: Beta 2.078.2

[Timothee Cour via Digitalmars-d-announce]

if necessary, to help with transition, one could add a hidden flag
`-log_when_issue_18315_occurred` that would log stacktrace (or maybe
user defined function) when hitting this condition at runtime:

```
void main(){ fun(int.min); }
void fun(int v){ writeln(v>0); }
```

dmd -log_when_issue_18315_occurred -run main.d
WARNING_18315 at (shows stacktrace): old:true, new:false
false


On Sun, Feb 4, 2018 at 3:01 PM, Timothee Cour  wrote:
> thanks @aG0aep6G for this PR https://github.com/dlang/dmd/pull/7841 to fix it.
> this should be in point release because:
> * ldc2 has correct behavior
> * the bug disappears with `-O`
> so the argument that ppl would rely on it is moot
>
>
> On Fri, Feb 2, 2018 at 6:37 AM, Steven Schveighoffer via
> Digitalmars-d-announce  wrote:
>> On 2/2/18 4:29 AM, Seb wrote:
>>>
>>> On Friday, 2 February 2018 at 08:34:32 UTC, Antonio Corbi wrote:
>>
>>
>>>> Wouldn't it be good to include a fix for errors like produced by int.min
>>>> assigned to a variable
>>>> (https://forum.dlang.org/post/p4l7kt$80d$1...@digitalmars.com) in a point
>>>> release like this?
>>>
>>>
>>> No, while I understand that you would like this to be fixed, this change
>>> might be disruptive - you never know on what weird behavior people rely.
>>> Anything potentially breaking existing code can't be part of a patch
>>> release.
>>
>>
>> In some cases, yes, we need to have a deprecation period as people may
>> depend on the behavior.
>>
>> In this case, however, the codegen is simply wrong. It can be fixed
>> immediately. I would hazard to guess that nobody is depending on int.min
>> being greater than 0.
>>
>>> Also AFAICT no one has submitted a PR to fix the issue you referenced, so
>>> it's a hypothetical question (for now).
>>
>>
>> I would suggest to would-be fixers, just do the correct thing that may be
>> less performant, and we can worry about optimizing later (and add a unit
>> test of course!). There is nothing worse than a compiler that doesn't emit
>> the code you expect it to.
>>
>> -Steve

Re: Beta 2.079.0

[Timothee Cour via Digitalmars-d-announce]

so how does one enforce that it imports `bar` as a module and not a
symbol in myModule when doing `import myModule : foo, bar;` ?
could this be supported:
`import myModule : foo, bar :`;
to break ambiguity?



On Tue, Feb 20, 2018 at 12:10 PM, jmh530 via Digitalmars-d-announce
 wrote:
> On Tuesday, 20 February 2018 at 20:08:55 UTC, jmh530 wrote:
>>
>> So in your example you know that bar is in myModule because bar is neither
>> fully qualified, nor is it fully qualified.
>>
>
> *nor does it have selective imports.

Re: Beta 2.079.0

[Timothee Cour via Digitalmars-d-announce]

you should also mention an important point:
current syntax disallows importing a simple module foo (with no package), eg:

import std.stdio:write,foo; // there's no way to specify a module `foo`
import std.stdio:write & foo; // ok

I don't care whether it's `|` or `&` but `,` as a module separator is
100% broken (and illegible, as you mentioned).




On Thu, Feb 22, 2018 at 12:42 AM, psychoticRabbit via
Digitalmars-d-announce  wrote:
> On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote:
>>
>> But it likely shouldn't be used in "real" applications; in particular, I
>> think it would be nice for the Phobos style guide to restrict/disallow its
>> use.
>
>
> grrr!
>
> better we get some common sense when implementing new stuff ;-)
>
> import std.stdio:write,writeln,writefln & std.array:join,split,replicate;
> vs
> import std.stdio:write,writeln,writefln,std.array:join,split,replicate;
>
> one is (AFAICT) already implemented, one is not.
>
> one is easy on the eyes (and therefore the brain), and one is not.
>
> one I would actually use, one I would not.
>
> one I would be ok for others to use, one I would not.
>
> can you guess which one applies to each case?
>

Re: Vision document for H1 2018

[Timothee Cour via Digitalmars-d-announce]

IMO this should be the priority:

1. blockers (things that can't be worked around at all or not without
jumping through a lot of hoops)
2. everything else

dmd still doesn't support shared libraries on OSX (cf
https://issues.dlang.org/show_bug.cgi?id=12190)

That prevents a whole category of use cases (eg D plugins called from
C++ or from D)





On Sat, Mar 10, 2018 at 8:06 PM, Nick Sabalausky (Abscissa) via
Digitalmars-d-announce  wrote:
> On 03/10/2018 05:47 AM, Dylan Graham wrote:
>>
>> On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote:
>>>
>>>
>>> According to the State of D Survey, 71% of the respondents don't care
>>> about betterC. Why is betterC on the priority list?
>>
>>
>> Yeah. Why should D worry about tying itself into C when it can't even
>> interface with itself through DLLs?
>
>
> First of all, betterC is about far more than interfacing with C. In fact,
> interop with C isn't really what betterC is about at all - that's a separate
> aspect of the language. (And those C/C++ users who still haven't come to D -
> for many of them the holdout is *because* of the issues betterC aims to
> address. Make no mistake, for all the stockholm syndrome in the C and C++
> worlds, there *are* a lot people openly wanting to jump ship but don't have
> a sufficient option yet. Heck, *I'm* a C/C++ -> D convert.)
>
> But more importantly:
>
> The D language itself is specifically designed and intended to be
> multi-purpose. Because of that, D users (and potential D users) are *highly*
> diverse. Everybody here has their own use-cases, their own needs and
> priorities, and their own list of things they want fixed yesterday.
>
> In a group this diverse, there just simply *isn't* much on the D wishlist
> that's crucially important to a *majority*, because we all need completely
> different things.
>
> Personally, better DLL support have little to no impact on me. Obviously it
> does for you, and I sympathise. Some of the things most important to me for
> D to improve you probably wouldn't care one bit about - and that's ok. We
> work on different sorts of things.
>
> Improved betterC is something I would find very nice if I ever have time or
> opportunity to get back into embedded software. But outside of that, yea, it
> doesn't impact me much more than it does for you.
>
> But here's the rub: In this crowd here, probably far more than most
> languages, we all have such wildly varying needs that 29% *is* what
> qualifies as significant around here. Most wishlist items are going to have
> similarly non-majority numbers. And they have to pick *something* to focus
> on. Luckily, as the vision document clearly states, there are *several* such
> "somethings" the dlang foundation is committing to working on.

Re: Blogpost about the T.init problem

[Timothee Cour via Digitalmars-d-announce]

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 { this.username = username; }

 invariant {
  if(this is typeof(this).init) return;
  assert(!username.empty);
}

 string toString() { return null; }

 ~this() @safe { }
}

void main(){
  Nullable!MyDomainData b;
}
```
On Thu, Jul 12, 2018 at 9:00 AM Luís Marques via
Digitalmars-d-announce  wrote:
>
> 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 enough. A number of
> > subtleties can only be assessed only by running the compiler,
> > not by perusing the specification. This semester we are pushing
> > for a better, more precise, and more complete specification of
> > the D language."
> >
> > ensuring that the language features are coherent together
>
> I think that point isn't supposed to be so ambitious. I think it
> only refers to the fact that the documentation isn't particularly
> formal/precise/complete regarding some language details. Making
> the language features more coherent and compatible among
> themselves is a whole other goal, independent of that one, IMO.