On Wednesday, 27 October 2021 at 13:57:50 UTC, Andrei Alexandrescu wrote:
> It's interesting that both you and Sebastiaan mention an "inverted delta" of sorts whereby current std is redone to use std2.

Well, generally new functions end up being more fundamental than old, so this is just naturally simpler.

In the case of the Windows functions, the Unicode functions can take any string the ANSI functions can, which is not true vice versa. So naturally, you'd be forced to write the less functional one in terms of the more functional one.

In the case of various Phobos modules:

* Removing autodecoding in v2 makes it more general. You can always write an autodecode function in terms of a plain function - just do a wrapper that adds the decode adapter.

Doing it the other way happens to be possible here too, using a byCodeUnit wrapper, but generally it is easier to add something in a wrapper than remove something that was already added.

* Some people hate std.socket because it uses classes. Well, if you build a std2.socket on top of it, those people will still be angry. But std2.socket could be a struct api and then the original std.socket class is built on top of it.

(in that case it would probably be a waste of time; just keeping the original std.socket unmodified - it is already a fairly thin layer on the underlying C functions anyway - and writing std2.socket right on top of the underlying C functions too is easy enough.)

* A generalization of std.socket: you can always build GC functions on top of @nogc foundations (e.g. `string toLower(string s) { return s.asLowerCase.array; } `). Not true other way around.

* If you want to trim down an interface, again, you can define std.v2 to be minimal then layer on stuff for compatibility on top. Users who stick to std.v2, importing just it and not the old one, they will not pay the cost of carrying these functions around.

But if you defined std.v2 on top of std.v1, it is impossible to remove functions. If a user imports std.v2, they automatically drag all the std.v1 baggage along too, whether they like it or not.

* Just as a matter of merge conflicts, making the bulk of your edits on the forward moving version is a more natural way to work.

The con here is maintaining compatibility with the old one is a bit harder since you're making edits and the old one might rely on it. But.... worse case you just copy/paste when the divergence is too much and lock in the old version letting the new one evolve.

On Wednesday, 27 October 2021 at 14:51:06 UTC, Steven Schveighoffer wrote:
> There is literally no way to reproduce the abomination known as an autodecoding for backwards compatibility. I tried.

in that case realistically you can't make a v2 act sane to strings when built on v1 either, meaning the only choice is to rewrite (aka copy/paste aka fork) as needed.

I'm ok with that.

On Wed, Oct 27, 2021 at 03:06:10PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Wednesday, 27 October 2021 at 14:51:06 UTC, Steven Schveighoffer wrote:
> > There is literally no way to reproduce the abomination known as an autodecoding for backwards compatibility. I tried.
> 
> in that case realistically you can't make a v2 act sane to strings when built on v1 either, meaning the only choice is to rewrite (aka copy/paste aka fork) as needed.
> 
> I'm ok with that.

Couldn't we just do something like this?

	// Phobos v1
	auto someStringFunc(R)(R range)
	{
		static if (willAutoDecode!R) {
			// old v1 code here
		} else {
			// thin wrapper over v2 code
		}
	}


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.

On Wed, Oct 27, 2021 at 01:04:25PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 10/27/21 12:33 PM, H. S. Teoh wrote:
> > On Wed, Oct 27, 2021 at 03:06:10PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> > > On Wednesday, 27 October 2021 at 14:51:06 UTC, Steven Schveighoffer wrote:
> > > > There is literally no way to reproduce the abomination known as an autodecoding for backwards compatibility. I tried.
> > > 
> > > in that case realistically you can't make a v2 act sane to strings when built on v1 either, meaning the only choice is to rewrite (aka copy/paste aka fork) as needed.
> > > 
> > > I'm ok with that.
> > 
> > Couldn't we just do something like this?
> > 
> > 	// Phobos v1
> > 	auto someStringFunc(R)(R range)
> > 	{
> > 		static if (willAutoDecode!R) {
> > 			// old v1 code here
> > 		} else {
> > 			// thin wrapper over v2 code
> > 		}
> > 	}
> 
> I'm not seeing the point. Why wrap v2 code when you are going to have to maintain the v1 code anyway?

I thought the you guys were arguing for making Phobos v1 a thin wrapper that forwards to v2 code.  If you wanted to retain a copy of v1 code, then this problem wouldn't come up at all?


> Plus, now it's a template that accepts ranges. Like it or not,
> `someStringFunc(string)` is not the same as `someStringFunc(R)(R)`.
[...]

Point.  So what, does that mean we're stuck with keeping v1 code around forever?

Honestly, I think a more practical approach is to give up the perfectionist ideal of old code compiling forever (the D community simply does not have the resources to maintain such a thing, unlike, say, MS Windows), and just do a best-efforts v1 emulation in v2 code, that will mostly work but may have a few rare cases where it won't compile, etc.. Then users just change the few bits that broke, and can continue enjoying v2 benefits.

//

Alternatively, here's a different approach: make v1 code a dub package, then break upstream Phobos at will to make v2.

Well OK, maybe have a transitional period where we maintain a copy of v1 code around, but with big fat warnings that within N months/years/etc. you will need to use the v1 dub package to continue compiling the code, or migrate to v2 now.  Once the transition period is over, we shed v1 code from upstream, but keep the dub package around for people who need it. There will be no more new features, only non-breaking bugfixes.


T

-- 
It only takes one twig to burn down a forest.