On 10/25/21 9:58 PM, zjh wrote:
> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>> Versioning Phobos would free us from maintaining backward
> 
> can we improve this
> ```d
> if (isInputRange!(Range1) && isInputRange!(Range2))
> ```
> to:
> ```d
> if isallInputRange(Range1,Range2)
> ```
> ?
> `C++`'s `concept` is very grace.
> 
> 

Easy in D but the following otherwise-attractive-short-hand-method imports symbols at module level (at least privately):

private import std.meta : allSatisfy;
private import std.range : isInputRange;

alias isallInputRange(T...) = allSatisfy!(isInputRange, T);

void foo(A, B)(A a, B b)
if (isallInputRange!(A, B)) {
}

unittest {
  static assert ( __traits(compiles, foo([0], [0])));
  static assert (!__traits(compiles, foo([0], 42)));
  static assert (!__traits(compiles, foo(42, [0])));
}

void main() {
}

Ali

On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
> Goals of library versioning:
>
> - avoid copy-and-paste code duplication across versions
This might be overengineering.  Unless new features are going to be backported to the original std, is there anything wrong with just forking std to std2?

On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>
> There are many other aspects to discuss, but I'll keep this short so the discussion doesn't meander too much.

The only problem I see when versioning the standard library is that some packages will rely on specific versions of the standard library and it could make it difficult to use packages that rely on different versions of the standard library.

In general I agree it would be a great idea, but we have to be careful about fragmenting things too much.

On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
> ...

I know this is basically a DOA suggestion, but what are your thoughts on embracing a package manager for the std?

For example, in C#-land any "additional" packages made by Microsoft are handled via the NuGet package manager, and are tagged in a way that aligns to the current version of .Net.

e.g. For .Net Core 3.1 the tag is v3.1.x, for 3.2 it's v3.2.x, etc.

https://www.nuget.org/packages/Microsoft.Extensions.Logging/

I'm not savvy enough to be able to state pros and cons though, so I leave that to others >;3

On Tuesday, 26 October 2021 at 06:03:38 UTC, sarn wrote:
> On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
>> Goals of library versioning:
>>
>> - avoid copy-and-paste code duplication across versions
> This might be overengineering.  Unless new features are going to be backported to the original std, is there anything wrong with just forking std to std2?

Yeah, I kind of agree there, just copy the stuff. Simple and effective; no crazy mixins or module aliases.

On Tuesday, 26 October 2021 at 01:19:29 UTC, Andrei Alexandrescu wrote:
> [...]

Probably not the best idea but also this should work:

std.... >

version(NEW)
{
.....
}
else
{
....
}

std2...>

version = NEW