On 2021-11-01 7:28, Johan wrote:
>>> I'm sorry to derail the topic of this thread, but rather than a discussion of how to implement the versioning, I would like to see a discussion first about what the user will see and how he is supposed to use it. I think the implementation of it is the easy part.
>>
>> I very strongly disagree.
> 
> Perhaps you misunderstood my point, but reading your mail I see we agree on most :) As you wrote a few sentences up, at least you agree that implementation is indeed easy ;-)

Thanks for clarifying.

> Just having clear examples of some code would really help paint the picture that indeed the future is bright with versioned stdlib.
> Breakage can be OK, if done deliberately and in a 'nice' way for the user to deal with; and versioning deliberately prevents breakage.
> 
>>> Is the user expected to completely migrate to use std.v3, or should he use a mix of std.v1, std.v2, std.v3?
>>
>> Up to them.
> 
> This is a big statement. For me this means:
> - v1 support is 'everlasting' and bugfixes will keep landing there too.

In the proposed scheme the marginal cost of keeping v1 around is very low. I'd say it's worth keeping it around until it becomes obsolete.

> - v2, v3, v4 will contain _all_ functionality that v1 has, and version x may be somewhere halfway on the path between v1 behavior and end goal behavior (e.g. some functions still do autodecoding and others don't).

That is correct. A fully release version worth announcing and advising users to switch to will offer all amenities v1 does, under hopefully a much better API. Once a new version is released, the only rationale to use it concurrently with the old one is during migration of user codebase.

> Another path would be to only add to v2 the functions that have changed, and for functionality that did not change the user should keep using v1.

This is what effectively happens in the implementation. But all names will be available under the new version. It would be onerous to ask users to use "std" for some artifacts and "std.v2" for others. Just use "std.v2" everywhere and you know you've migrated.

>>> Will there be autodecoding functions in v3?
>>
>> Probably not. But there will be decoding functions in v3.
> 
> Removing the "auto" part sounds very good indeed.

Can't wait!

On Monday, 1 November 2021 at 13:01:26 UTC, bachmeier wrote:
> It's useless trying to update pieces that are in the standard, and there was no process for updating the standard. The result was a boring language frozen in time. Matches up nicely with the low-hanging fruit Andrei listed.

There should certainly be a process for adding to a standard library, but "standard" usually means that you remain backwards compatible at the interface level for a very long time.

The core problem is not having a layered approach where you keep the stable inner core minimal. Then you can have other layers on top of that are application level libraries.

So for instance, you could have a higher level "ranges library" that is official, but that can be wholesale replaced if need be, without affecting code that only depend on the core.

Or you can do like Ada and have different profiles for different usage/hardware scenarios.

(I am leaving Lisp aside, as many considered it an archaic minimalistic language by the 1980s. The culture that ensured Lisp a prolonged life is rather peculiar and unusual.)


>> The std lib should be the bottom layer, and small, so you can keep it stable, efficient and provide targeted compiler optimizations.
>
> This is an argument in favor of versioning. V1 can have all those properties, and subsequent versions can build on it.

If you only extend, but then you don't need explicit versioning. Versioning the language/compiler would be sufficient.

I remain skeptical this scheme will work as well when we get into the rest of the changes.... but I'm happy to see any action. Been too long with nothing. Even if the scheme doesn't work that well, let's just do it.

On 2021-11-01 9:48, Adam D Ruppe wrote:
> I remain skeptical this scheme will work as well when we get into the rest of the changes.... but I'm happy to see any action. Been too long with nothing. Even if the scheme doesn't work that well, let's just do it.

It all hinges on documentation, which is the most needed piece. I think the string mixins in the implementation are tolerable.

Either we use adrdox or improve ddoc.

On Mon, Nov 01, 2021 at 09:52:31AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> Either we use adrdox or improve ddoc.

I vote for integrating adrdox into ddoc.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

On Mon, Nov 01, 2021 at 01:37:56PM +0000, zjh via Digitalmars-d wrote:
> On Monday, 1 November 2021 at 13:19:04 UTC, Andrei Alexandrescu wrote:
> > On 2021-10-31 23:49, zjh wrote:
> > > We don't need to be better than
> 
> Good, I just want to repeat, I hope `d` can remain work hard on `metaprogramming`, so that other languages can't compete with `d` in `metaprogramming`. In this way, I can big blow `d` language in QQ group.  Maintain the advantage of Dlang's `metaprogramming`, and users of other languages will be attracted.

Lost in translation: "big blow" -> "heavily promote". ;-)


T

-- 
By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth

On Monday, 1 November 2021 at 14:07:35 UTC, H. S. Teoh wrote:
> On Mon, Nov 01, 2021 at 01:37:56PM +0000, zjh via Digitalmars-d

大吹特吹,百度的翻译.就这样,请理解.

On Mon, Nov 01, 2021 at 02:09:44PM +0000, Ogi via Digitalmars-d wrote:
> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
> > https://github.com/dlang/phobos/pull/8309
> > 
> > Destroy!
> 
> Good stuff.
> 
> Notably absent are `std.range.interfaces`. What are we going to do about them?

I think Andrei has indicated in the past that we want to get rid of it.

But IMO, practically speaking, sometimes object wrappers for ranges are necessary. For example, if you need to alternate between two incompatible UFCS chains based on a runtime condition (so you can't use std.range.choose), or you need to return one UFCS chain or another from a function based on a runtime condition:

	// This will not compile because of divergent return types.
	auto runtimeChoice(R)(R srcRange, bool condition) {
		if (condition)
			return srcRange.filter!someCriterion;
		else
			return srcRange.map!(x => someMap(x))
					.filter!someCriterion;
	}

	// So we need to do this instead:
	auto runtimeChoice(R)(R srcRange, bool condition) {
		if (condition)
			return inputRangeObject(srcRange.filter!someCriterion);
		else
			return inputRangeObject(srcRange.map!(x => someMap(x))
						.filter!someCriterion);
	}

Phobos v2 better have a way to deal with this.  Either that, or keep the current definition of forward ranges until v3, to avoid too massive a change.


T

-- 
There are two ways to write error-free programs; only the third one works.

On Monday, 1 November 2021 at 08:08:32 UTC, Ola Fosheim Grøstad wrote:

> Freezing D2 and starting on D3 would be a much better approach and would allow you to pick up ideas from other languages than C++ (e.g. Rust, Pony etc).

I also agree with this!

You build a future with the past in mind, not with you or it will become a burden

Python 2 -> 3  saved the language, it gave it a new youth