feat: Make GenericPath.normalize return itself

[Geod24]

This makes writing code much easier as can be seen in the unittest.

[s-ludwig]

There is also the .normalized property. The only issue I see with this change is that one might assume that .normalize doesn't have side-effects, although this would usually not be a problem.

[Geod24]

I think the two different name, and the fact that normalize isn't const, should make this pretty obvious ? The documentation is also fairly clear IMO.

[s-ludwig]

I think the two different name, and the fact that normalize isn't const, should make this pretty obvious ? The documentation is also fairly clear IMO.

That just doesn't help much when reading the code or when using auto-completion to write it. The counter question would be whether there is actual code that would want to use .normalize like this instead of .normalized. In general, I'm only using the return this API pattern in very specific places where method call chaining is an explicit feature, which also makes this a slightly surprising outlier.

Having said that, I really don't have a particularly strong opinion on this, but I think this change should be supported by good reasoning.

On a tangential note, going by the implementation, it seems like normalize() should really call normalized() instead of the other way around here. I'll note that for a future change.

[Geod24]

My use case was simply SomePath(validated_string).normalize().

Because I checked the code, I know that normalized creates a new object but normalize doesn't, and intuitively it seemed better to call normalize on a just-constructed object than to immediately make a copy. Since GenericPath is just a struct wrapper, that probably actually doesn't make a difference.

For dub I ended up exposing a struct that wraps GenericPath!T with an opBinary that always normalize, as the code relied on this and I was not confident I could go over all cases where we appended path. So return typeof(this)(this.data.opBinary!op(arg).normalize()) is nice, and also feels wasteful to do a copy if you have an in-place method.

[s-ludwig]

Okay, that makes sense. I've pushed a change to move the implementation to normalize and also attached the main doc comment to it, to emphasize it more. Since GenericPath stores the path as a single string, there is nothing to gain from in-place modification anyway so that normalize will only ever be a convenience shortcut for path = path.normalized.

[Geod24]

I would suggest deprecating it then.