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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017



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 2017



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 2017



 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 2017



  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 2017



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 2017



 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 2017



  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 2017



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 2017



  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 2017



  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 2017



  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 2017



  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 2017



  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 2017



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 2017