I recently noticed vibe.d now using main loop which call the vibe.d event loop. Why that change?

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. Why that change?

Like:

#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
import vibe.d;

void main()
{
    auto settings = new HTTPServerSettings;
    settings.port = 8080;

    listenHTTP(settings, (req, res) { res.writeBody("Hello Vibe.d: " ~ req.path); });
    runApplication();
}

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. Why that change?

I can only assume it's because static constructors are a pain in the ass.

https://dlang.org/spec/module.html#order_of_static_ctor

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.

On Sunday, 25 February 2018 at 01:15:06 UTC, Seb wrote:
> 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 ;-)
That's how I've been doing it http://aberba.com/2016/form-upload-in-vibe-d/
>
> ---
>
> 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

I should take these changelogs seriously and read into details.
>
> ---
>
>
>> 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.
Oh. I've been using "static this". Noted.
>
>
> 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.

static this seemed clean though :)