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.

Tbh. it should just have been marked with deprecated instead of being removed, as you do specify is the normal deprecation process.

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.

On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:
> 		private Nullable!string _path;

Also does this really make sense?

Why not just have it:

private string _path;

Then instead of:
		string path() @safe {
			if (_path.isNull) {
				_path = urlDecode(requestPath.toString);
			}
			return _path.get;
		}

You could have:
		string path() @safe {
			if (!_path) {
				_path = urlDecode(requestPath.toString);
			}
			return _path;
		}

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.

Am 17.12.2017 um 21:56 schrieb bauss:
> On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:
>>         private Nullable!string _path;
> 
> Also does this really make sense?
> 
> Why not just have it:
> 
> private string _path;
> 
> Then instead of:
>          string path() @safe {
>              if (_path.isNull) {
>                  _path = urlDecode(requestPath.toString);
>              }
>              return _path.get;
>          }
> 
> You could have:
>          string path() @safe {
>              if (!_path) {
>                  _path = urlDecode(requestPath.toString);
>              }
>              return _path;
>          }

That would certainly be possible. Using a `Nullable` is mainly just more explicit.