www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - vibe.d 0.8.0 and 0.7.31 beta releases

reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
The first release of the revamped core module [1] is nearing, and along 
with that, a compatible vibe.d release (0.8.0). The new core module is 
still opt-in in this release and can be activated using a 
`subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl 
(`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).

In parallel to the 0.8.x branch, the 0.7.x branch will stay maintained 
for a while, but the 0.7.31 release will be the last one to contain new 
features. For anyone who does not depend on old D frontends, it is 
strongly recommended to switch to the 0.8.x branch as soon as possible 
and also to test with vibe-core (production deployments are safer off 
staying with the old :core module for now), as the transition period is 
supposed to be only as long as necessary to guarantee a stable 
implementation.

To give an overview, here is the list of the biggest changes:

- The whole library is now split into fully separate sub packages. This
   required some code changes, because there were some hidden circular
   dependencies between modules. Some parts have also been moved to the
   new sub packages "stream", "textfilter", "crypto" and "inet".

- Large parts of the API are now annotated with nothrow and  safe. In
   case of APIs that depend on callbacks, these can be breaking changes,
   but the most prominent places have deprecation paths in place.

- The vibe-d:core sub module has got a new configuration "vibe-core"
   that causes it to be replaced by the vibe-core package.

- The stream API has been made forward compatible with vibe-core. This
   adds optional IOMode parameters to the read/write methods (the value
   is currently ignored) and deprecates the leastSize and
   dataAvailableForRead properties.

The full change log for can be found at 
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

DUB pages:
http://code.dlang.org/packages/vibe-d/0.8.0-beta.1
http://code.dlang.org/packages/vibe-d/0.7.31-beta.1

[1]: https://github.com/vibe-d/vibe-core
Jan 31
next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 For anyone who does not depend on old D frontends, it is 
 strongly recommended to switch to the 0.8.x branch
What do you mean here by "old D frontends"? What are minimal dmd versions for 0.7 and 0.8 branches?
Jan 31
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 31.01.2017 um 12:56 schrieb thedeemon:
 On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 For anyone who does not depend on old D frontends, it is strongly
 recommended to switch to the 0.8.x branch
What do you mean here by "old D frontends"? What are minimal dmd versions for 0.7 and 0.8 branches?
0.7.31 will work with 2.069-2.073 and 0.8.0 will work with 2.070-2.073. This is especially interesting because GDC master is still on 2.069.x.
Jan 31
parent thedeemon <dlang thedeemon.com> writes:
On Tuesday, 31 January 2017 at 13:27:31 UTC, Sönke Ludwig wrote:

 0.7.31 will work with 2.069-2.073 and 0.8.0 will work with 
 2.070-2.073. This is especially interesting because GDC master 
 is still on 2.069.x.
Thanks!
Jan 31
prev sibling next sibling parent wobbles <grogan.colin gmail.com> writes:
On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 The first release of the revamped core module [1] is nearing, 
 and along with that, a compatible vibe.d release (0.8.0). The 
 new core module is still opt-in in this release and can be 
 activated using a `subConfiguration "vibe-d:core" "vibe-core"` 
 directive in dub.sdl (`"subConfigurations": {"vibe-d:core": 
 "vibe-core"}` in dub.json).

 [...]
Very nice! Thanks for all your work on this - excellent stuff.
Jan 31
prev sibling next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 [1]: https://github.com/vibe-d/vibe-core
Is vibe-core still in alpha stage? Github page says so.
Jan 31
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 31.01.2017 um 20:38 schrieb Arun Chandrasekaran:
 On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 [1]: https://github.com/vibe-d/vibe-core
Is vibe-core still in alpha stage? Github page says so.
It's de-facto beta stage, but I still need to add a beta tag and update the description. My hope was to get a little bit of practical feedback from others before the beta stage officially starts, but apart from possible cosmetics or small additions, the API is now finalized and all tests pass.
Feb 01
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
 The first release of the revamped core module [1] is nearing, and along
 with that, a compatible vibe.d release (0.8.0). The new core module is
 still opt-in in this release and can be activated using a
 `subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl
 (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).
Forgot to mention: Due to the way DUB currently handles "subConfigurations", an explicit dependency to "vibe-d:core" must also be present in the same package recipe, or it will silently do nothing. I'll try to improve this for the next release.
Feb 01
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig wrote:
 Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
 The first release of the revamped core module [1] is nearing, 
 and along
 with that, a compatible vibe.d release (0.8.0). The new core 
 module is
 still opt-in in this release and can be activated using a
 `subConfiguration "vibe-d:core" "vibe-core"` directive in 
 dub.sdl
 (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in 
 dub.json).
Forgot to mention: Due to the way DUB currently handles "subConfigurations", an explicit dependency to "vibe-d:core" must also be present in the same package recipe, or it will silently do nothing. I'll try to improve this for the next release.
I don't understand what you mean. Will vibe-d:core be added as s dependency?
Feb 01
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 01.02.2017 um 10:46 schrieb aberba:
 On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig wrote:
 Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
 The first release of the revamped core module [1] is nearing, and along
 with that, a compatible vibe.d release (0.8.0). The new core module is
 still opt-in in this release and can be activated using a
 `subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl
 (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).
Forgot to mention: Due to the way DUB currently handles "subConfigurations", an explicit dependency to "vibe-d:core" must also be present in the same package recipe, or it will silently do nothing. I'll try to improve this for the next release.
I don't understand what you mean. Will vibe-d:core be added as s dependency?
So you need to have both, subConfiguration(s) and dependenc(y/ies) in the package recipe, for example: name "foo" dependency "vibe-d:web" version="~>0.8.0-beta" // <- this would usually be the only dependency necessary, // but the following one is necessary so that subConfiguration // actually works: dependency "vibe-d:core" version="~>0.8.0-beta" subConfiguration "vibe-d:core" "vibe-core"
Feb 01
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote:
 Am 01.02.2017 um 10:46 schrieb aberba:
 On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig 
 wrote:
 Am 31.01.2017 um 12:11 schrieb Sönke Ludwig:
 The first release of the revamped core module [1] is 
 nearing, and along
 with that, a compatible vibe.d release (0.8.0). The new core 
 module is
 still opt-in in this release and can be activated using a
 `subConfiguration "vibe-d:core" "vibe-core"` directive in 
 dub.sdl
 (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in 
 dub.json).
Forgot to mention: Due to the way DUB currently handles "subConfigurations", an explicit dependency to "vibe-d:core" must also be present in the same package recipe, or it will silently do nothing. I'll try to improve this for the next release.
I don't understand what you mean. Will vibe-d:core be added as s dependency?
So you need to have both, subConfiguration(s) and dependenc(y/ies) in the package recipe, for example: name "foo" dependency "vibe-d:web" version="~>0.8.0-beta" // <- this would usually be the only dependency necessary, // but the following one is necessary so that subConfiguration // actually works: dependency "vibe-d:core" version="~>0.8.0-beta" subConfiguration "vibe-d:core" "vibe-core"
Still does not works, it always try to build vibe-d:core with libevent, only way how to avoid it, is to manualy remove all others configurations from vibe-d:core dub.sdl
Feb 13
parent Daniel Kozak via Digitalmars-d-announce writes:
Dne 13.2.2017 v 23:49 Daniel Kozak via Digitalmars-d-announce napsal(a):

 On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote:

 Still does not works, it always try to build vibe-d:core with 
 libevent, only way how to avoid it, is to manualy remove all others 
 configurations from vibe-d:core dub.sdl
Ok my mistake https://github.com/dlang/dub/issues/1074#issuecomment-279561833
Feb 13
prev sibling next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
0.8.0-beta.2 and 0.7.31-beta.2 have been tagged now and fix the issues 
found so far.
Feb 02
prev sibling next sibling parent reply yazd <email email.com> writes:
On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 The first release of the revamped core module [1] is nearing, 
 and along with that, a compatible vibe.d release (0.8.0). The 
 new core module is still opt-in in this release and can be 
 activated using a `subConfiguration "vibe-d:core" "vibe-core"` 
 directive in dub.sdl (`"subConfigurations": {"vibe-d:core": 
 "vibe-core"}` in dub.json).
I am always excited to see a new release of vibe-d. Thank you!
 - Large parts of the API are now annotated with nothrow and 
  safe. In
   case of APIs that depend on callbacks, these can be breaking 
 changes,
   but the most prominent places have deprecation paths in place.
Is it possible to have non- safe callbacks be part of the non-deprecated API? Personally, I think safe adds very little value compared to the headaches it causes and the time and efforts required to have every piece of your code properly annotated (it is sometimes impossible when using dependencies or even phobos and druntime without going into the lengthy process of doing upstream changes and waiting for new versions). I don't think it adds value because I write my code in idiomatic D, which is mostly safe in reality but not necessarily safe compliant. On the other hand, I am all for nothrow changes.
Feb 03
next sibling parent reply Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
 Is it possible to have non- safe callbacks be part of the 
 non-deprecated API?
Why? A safe API allows you to use it within safe code, but it doesn't require you to also write safe code. Especially if you don't like to annotate your code to be safe, even if you think it is safe, this doesn't hinders you to use other peoples safe code. Only the reverse is a problem (other people, who like to annotate their code safe, can't use your code if it is not annotated - so they start to ignore your code even if it would be safe only because you don't bother).
Feb 03
parent yazd <email email.com> writes:
On Friday, 3 February 2017 at 12:25:42 UTC, Dominikus Dittes 
Scherkl wrote:
 On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
 Is it possible to have non- safe callbacks be part of the 
 non-deprecated API?
Why? A safe API allows you to use it within safe code, but it doesn't require you to also write safe code. Especially if you don't like to annotate your code to be safe, even if you think it is safe, this doesn't hinders you to use other peoples safe code. Only the reverse is a problem (other people, who like to annotate their code safe, can't use your code if it is not annotated - so they start to ignore your code even if it would be safe only because you don't bother).
What you are saying is true when you are the caller, but in this case, the callbacks provided to the API are what is required to be safe and accordingly my code is required to be safe. For example, this is the signature for `setTimer`: Timer setTimer(Duration timeout, void delegate() nothrow safe callback, bool periodic = false) safe nothrow; I can't even use `logInfo("%s", ex)` where `ex` is an `Exception` in safe code, because `Exception.toString()` isn't safe and it can't be safe because it is a virtual function, and there are many cases of such problems.
Feb 03
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 03.02.2017 um 10:28 schrieb yazd:
 On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
 The first release of the revamped core module [1] is nearing, and
 along with that, a compatible vibe.d release (0.8.0). The new core
 module is still opt-in in this release and can be activated using a
 `subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl
 (`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).
I am always excited to see a new release of vibe-d. Thank you!
 - Large parts of the API are now annotated with nothrow and  safe. In
   case of APIs that depend on callbacks, these can be breaking changes,
   but the most prominent places have deprecation paths in place.
Is it possible to have non- safe callbacks be part of the non-deprecated API? Personally, I think safe adds very little value compared to the headaches it causes and the time and efforts required to have every piece of your code properly annotated (it is sometimes impossible when using dependencies or even phobos and druntime without going into the lengthy process of doing upstream changes and waiting for new versions). I don't think it adds value because I write my code in idiomatic D, which is mostly safe in reality but not necessarily safe compliant. On the other hand, I am all for nothrow changes.
Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). I agree that currently the effort/benefit ratio is rather limited, because there are still many areas in Druntime/Phobos that have not been updated, and because there are still some big holes in the system. However, there are two critical reasons why I still want to embrace it for vibe.d. First, it actually has helped to detect some rather subtle issues in the past that have gone unnoticed for a long time otherwise. And, maybe more importantly, annotating code as safe is the only way to guarantee proper bounds checks, which is critical for a server component. And finally, I feel that if nobody starts to embrace this on a broader level now, it will never reach a truly mature state. If you really don't care about these annotations, you can always simply put a " trusted:" at the top of the module/class and be done with it. But since vibe.d is now annotated with safe, as well as an ever growing subset of Phobos/Druntime, writing with annotations is actually quite painless, except possibly for third party dependencies, of course*. * The most annoying thing I found the language itself was that .byKey for associative arrays is system.
Feb 03
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
 Am 03.02.2017 um 10:28 schrieb yazd:
 [...]
Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). [...]
How does vibed comply with https://blog.appcanary.com/2017/http-security-headers.html
Feb 06
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 06.02.2017 um 14:35 schrieb aberba:
 On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
 Am 03.02.2017 um 10:28 schrieb yazd:
 [...]
Keeping the system overloads would break the safety guarantees at a relatively deep level and would render the whole effort rather useless (this is the case for non-scope callbacks only, so if you stumble over a deprecated function with a scope callback, then it should be fixed). [...]
How does vibed comply with https://blog.appcanary.com/2017/http-security-headers.html
The headers currently have to be set manually (for example using route.any("*", &addHeaders); as the first route). But for the high-level vibe.web package I'm planning to let them be set automatically (with the possibility to opt out), so that there is a safe default.
Feb 06
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
 Keeping the system overloads would break the safety guarantees 
 at a relatively deep level and would render the whole effort 
 rather useless (this is the case for non-scope callbacks only, 
 so if you stumble over a deprecated function with a scope 
 callback, then it should be fixed).
That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee.
 First, it actually has helped to detect some rather subtle 
 issues in the past that have gone unnoticed for a long time 
 otherwise.
Being safe-compatible and provide safe guarantees are different issues. The latter follows from the former if user code is safe and doesn't follow otherwise.
 And, maybe more importantly, annotating code as safe is the 
 only way to guarantee proper bounds checks, which is critical 
 for a server component.
-boundscheck=on should do it, ldc provides even more control how code is compiled.
 And finally, I feel that if nobody starts to embrace this on a 
 broader level now, it will never reach a truly mature state.
Fake trusted annotations don't count as adoption of safety. Pedantically speaking safe loses its purpose if trusted code is not verified. Especially if fake trusted becomes a habit. That's why safety can't be forced and is opt-in.
Feb 08
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
Am 08.02.2017 um 11:30 schrieb Kagamin:
 On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
 Keeping the system overloads would break the safety guarantees at a
 relatively deep level and would render the whole effort rather useless
 (this is the case for non-scope callbacks only, so if you stumble over
 a deprecated function with a scope callback, then it should be fixed).
That's kind of intended: the system would inherit safety of the code it calls. If the user code is not safe, there's no safety guarantee.
The problem is that there are two affected call stacks - the system API function that registers the system callback, wrapping/casting it as trusted, and the event handler that later on actually calls the callback. The latter place is where the hidden violation of the safe guarantees happens.
 First, it actually has helped to detect some rather subtle issues in
 the past that have gone unnoticed for a long time otherwise.
Being safe-compatible and provide safe guarantees are different issues. The latter follows from the former if user code is safe and doesn't follow otherwise.
True, but that goes a bit beside my point. I was just arguing in favor of the safe system in general here, not about this particular instance.
 And, maybe more importantly, annotating code as safe is the only way
 to guarantee proper bounds checks, which is critical for a server
 component.
-boundscheck=on should do it, ldc provides even more control how code is compiled.
True, but that also imposes this restriction on all user code, while just requiring -boundscheck=safeonly would enable dependent packages to make a choice (aside from manually sidestepping boundschecks in code).
 And finally, I feel that if nobody starts to embrace this on a broader
 level now, it will never reach a truly mature state.
Fake trusted annotations don't count as adoption of safety. Pedantically speaking safe loses its purpose if trusted code is not verified. Especially if fake trusted becomes a habit. That's why safety can't be forced and is opt-in.
I agree with the pedantic statement, but not with the conclusion. Right now it's simply not possible in practice to write either fully compiler checked code or fully audited trusted code on a large scale. But starting to work towards a fully compiler checked code base makes all of the missing spots visible, so that there is more pressure to actually fix them. I was actually considering to open PRs for each instance, but it quickly became clear that it were too many places for me to be able to do that in a reasonable time frame (also, trusted is still necessary to support old compiler versions), so that had to be postponed.
Feb 08
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
 The problem is that there are two affected call stacks - the 
  system API function that registers the  system callback, 
 wrapping/casting it as  trusted, and the event handler that 
 later on actually calls the callback. The latter place is where 
 the hidden violation of the  safe guarantees happens.
Hidden from whom? Since it's user, who supplies system code to vibe, he knows that the resulting program doesn't provide safe guarantees. It can be communicated at the API level: int f( safe void delegate() dg) safe { code } int f( system void delegate() dg) system { return f(cast( safe void delegate())dg); } So that unsafe overload would be only callable from unsafe code.
Feb 09
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 09.02.2017 um 18:00 schrieb Kagamin:
 On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
 The problem is that there are two affected call stacks - the  system
 API function that registers the  system callback, wrapping/casting it
 as  trusted, and the event handler that later on actually calls the
 callback. The latter place is where the hidden violation of the  safe
 guarantees happens.
Hidden from whom? Since it's user, who supplies system code to vibe, he knows that the resulting program doesn't provide safe guarantees. It can be communicated at the API level: int f( safe void delegate() dg) safe { code } int f( system void delegate() dg) system { return f(cast( safe void delegate())dg); } So that unsafe overload would be only callable from unsafe code.
Hidden from the code that calls the callback. This may be an acceptable trade off in this particular case, because this is crossing a library border, but in general this is just misuse of the safety system, since the effects of the cast leave the scope of system/ trusted. I don't know, I don't really like this, but maybe I should just postpone the `deprecated` attribute to be added for 0.8.1 to leave more room for a final decision.
Feb 09
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 9 February 2017 at 19:40:45 UTC, Sönke Ludwig wrote:
 Am 09.02.2017 um 18:00 schrieb Kagamin:
 On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig 
 wrote:
 The problem is that there are two affected call stacks - the 
  system
 API function that registers the  system callback, 
 wrapping/casting it
 as  trusted, and the event handler that later on actually 
 calls the
 callback. The latter place is where the hidden violation of 
 the  safe
 guarantees happens.
Hidden from whom? Since it's user, who supplies system code to vibe, he knows that the resulting program doesn't provide safe guarantees. It can be communicated at the API level: int f( safe void delegate() dg) safe { code } int f( system void delegate() dg) system { return f(cast( safe void delegate())dg); } So that unsafe overload would be only callable from unsafe code.
Hidden from the code that calls the callback. This may be an acceptable trade off in this particular case, because this is crossing a library border, but in general this is just misuse of the safety system, since the effects of the cast leave the scope of system/ trusted. I don't know, I don't really like this, but maybe I should just postpone the `deprecated` attribute to be added for 0.8.1 to leave more room for a final decision.
Just ran in to this trying to update a large project to 0.7.31-rc.2. The change to HTTPServerRequestDelegate breaks code where we have system callbacks that it would not be sensible to make trusted at the moment. What can we do?
Mar 28
parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 28.03.2017 um 15:46 schrieb John Colvin:
 On Thursday, 9 February 2017 at 19:40:45 UTC, Sönke Ludwig wrote:
 Am 09.02.2017 um 18:00 schrieb Kagamin:
 On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:
 The problem is that there are two affected call stacks - the  system
 API function that registers the  system callback, wrapping/casting it
 as  trusted, and the event handler that later on actually calls the
 callback. The latter place is where the hidden violation of the  safe
 guarantees happens.
Hidden from whom? Since it's user, who supplies system code to vibe, he knows that the resulting program doesn't provide safe guarantees. It can be communicated at the API level: int f( safe void delegate() dg) safe { code } int f( system void delegate() dg) system { return f(cast( safe void delegate())dg); } So that unsafe overload would be only callable from unsafe code.
Hidden from the code that calls the callback. This may be an acceptable trade off in this particular case, because this is crossing a library border, but in general this is just misuse of the safety system, since the effects of the cast leave the scope of system/ trusted. I don't know, I don't really like this, but maybe I should just postpone the `deprecated` attribute to be added for 0.8.1 to leave more room for a final decision.
Just ran in to this trying to update a large project to 0.7.31-rc.2. The change to HTTPServerRequestDelegate breaks code where we have system callbacks that it would not be sensible to make trusted at the moment. What can we do?
Are you sure that you didn't get 0.8.0-beta.x by accident? The 0.7.31 release shouldn't contain any safety related changes. 0.8.0 is supposed to handle any system-callbacks gracefully, though, can you post the line that fails, possibly along with the signature of the handler function?
Mar 28
prev sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
The third release candidate of 0.7.31 has been tagged (the two previous 
ones still had issues, so I skipped the announcement). Contrary to the 
initial plan, 0.7.31 will be released prior to 0.8.0, which still can 
use a little more time to mature.

If you plan to stay on the 0.7.x branch, please take the opportunity to 
test this (e.g. keep dependency to `~>0.7.30` and then do `dub upgrade 
--prerelease`). The final release is scheduled for next Monday (April 10th).

Change log:
https://github.com/rejectedsoftware/vibe.d/blob/0.7.x/CHANGELOG.md

DUB: https://code.dlang.org/packages/vibe-d/0.7.31-rc.3
Apr 02