Vibe.d no more using static this() {}

[Seb]

On Friday, 23 February 2018 at 23:11:13 UTC, aberba wrote:
> I recently noticed vibe.d now using main loop which call the 
> vibe.d event loop.

"Recently"?
FWIW this has been phased out a long time ago ;-)

---

0.7.23 (2015)

> Definition of either VibeCustomMain or VibeDefaultMain is now a 
> hard requirement - this is the final deprecation phase for 
> VibeCustomMain

https://github.com/vibe-d/vibe.d/blob/master/CHANGELOG.md#features-and-improvements-10

> Added a compile time warning when neither VibeCustomMain, nor 
> VibeDefaultMain versions are specified - starts the transition 
> from VibeCustomMain to VibeDefaultMain

https://github.com/vibe-d/vibe.d/blob/master/CHANGELOG.md#features-and-improvements-14


0.7.30 (2016)

> Added runApplication as a single API entry point to properly 
> initialize and run a vibe.d application (this will serve as the 
> basis for slowly phasing out the VibeDefaultMain convenience 
> mechanism)

https://github.com/vibe-d/vibe.d/blob/master/CHANGELOG.md#features-and-improvements-4

---


> Why that change?

In short, because there are too many problems with starting the 
eventloop by default without stating so and requiring the user to 
know what's going on. I don't know all the reasons, but one 
example that comes to my mind is that if you use Vibe.d for a 
simple curl-like script, you might be wondering why it never 
exits.
Also you mention `static this` in your title, but usually `shared 
static this` should be used.


There are also other concerns, e.g. the @safe-ty of the eventloop 
is never checked when you use the default main method.


Hence, in 2014 VibeDefaultMain was introduced to move away 
VibeCustomMain (which required the user to take explicit action 
when the eventloop shouldn't run).

Nowadays, a user neds to choose whether to use the default main 
loop (versions "VibeDefaultMain") or call 
runEventLoop/runApplication, but "VibeDefaultMain" with shared 
static this is deprecated.