Released vibe.d 0.8.2
Sönke Ludwig
sludwig+d at outerproduct.org
Sun Dec 17 21:07:01 UTC 2017
Am 17.12.2017 um 21:55 schrieb bauss:
> On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:
>> But what do you mean with anything will break using `.path`? It
>> follows the usual deprecation path - currently it's just documented as
>> deprecated. In one or two releases, the `deprecated` attribute will be
>> set and a few releases later it will finally be removed. By that time
>> projects will have had quite some time to react on the deprecation.
>
> HTTPServerRequest.path does not have the same definition as previously.
>
> It has been changed from a field to a getter function.
True, this can be a breaking change, but setting this field looks like
something that is outside of any sane use case. The field should ideally
have been const/immutable before.
>
> Tbh. it should just have been marked with deprecated instead of being
> removed, as you do specify is the normal deprecation process.
What do you mean with this? Keeping the field with a `deprecated`
attribute, and at the same time add the getter property?
>
> 0.8.1:
> /** The _path part of the URL.
>
> Remarks: This field is only set if
> HTTPServerOption.parseURL is set.
> */
> string path;
>
> 0.8.2:
> /** Deprecated: The _path part of the URL.
>
> Note that this function contains the decoded version of the
> requested path, which can yield incorrect results if the path
> contains URL encoded path separators. Use `requestPath`
> instead to
> get an encoding-aware representation.
> */
> string path() @safe {
> if (_path.isNull) {
> _path = urlDecode(requestPath.toString);
> }
> return _path.get;
> }
>
> private Nullable!string _path;
>
> There should still have been a setter property like:
>
> void path(string newPath);
>
> Which should be marked with deprecated until it could be safely removed.
More information about the Digitalmars-d-announce
mailing list