On 11/1/21 10:09 AM, Ogi 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 don't think they need particular attention - either publish them as they are, change them, or give up on them altogether (I believe allowing ref-type ranges was a mistake).

On Mon, Nov 01, 2021 at 11:39:46AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 11/1/21 10:09 AM, Ogi 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 don't think they need particular attention - either publish them as they are, change them, or give up on them altogether (I believe allowing ref-type ranges was a mistake).

So what do we do with functions that need to return ranges of multiple types (albeit with compatible element types)?  Like std.range.choose except with a runtime condition.  Or functions that return ranges whose concrete types are not known until runtime?

If classes are not the answer, then what's the alternative?


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

On 2021-11-01 11:00, jmh530 wrote:
> On Monday, 1 November 2021 at 13:18:07 UTC, Andrei Alexandrescu wrote:
>> [snip]
>>
>> The problem with C++ concepts is that they invent yet another language on the top of the three C++ already has in it. It is a massive mistake, though not big enough to destroy the language. C++ continues to be successful in spite of it, not because of it.
>>
>> The right way is to express concepts within the current language and algebra, as D does.
> 
> I know that it is kind of tangential to the PoC, but the point that was raised is that concepts/etc resolve the issue of the "proper documenting of API's". Your response is that concepts are bad because they create a new language and it is better to express them within the current language, as in D. This is all fine, but it doesn't resolve the issue of "proper documenting of APIs" issue. Both points can be valid at the same time (concepts might be bad for the reasons you mention but D may still have an underlying issue wrt proper documenting of APIs).
> 
> My hope was that DIP 1023 (Resolution of Template Alias Formal Parameters in Template Functions [1]) would help on this issue, but it has been postponed and I believe the original author has moved on. Regardless, the code below has the example of an template alias that is used like a C++ concept.
> 
> ```d
> template Foo(T)
>      if (is(T == int))
> {
>      alias Foo = T;
> }
> 
> void foo(T)(Foo!T x) { }
> 
> void main() {
>      Foo!int x;
>      foo(x); //doesn't compile
>      foo!int(x); //compiles
> }
> ```
> 
> The only problem is the resolution. I don't see why you would need concepts in D if this issue is resolved.
> 
> [1] https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md

That code looks pretty damn cool.

On 11/1/21 10:54 AM, user1234 wrote:
> On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
>> https://github.com/dlang/phobos/pull/8309
>>
>> Destroy!
> 
> Two questions, probably related to `canon`. I assume that two things are possible but I dont see how:
> 
> 1. How does the module identifier part `v1` binds a current module name ?
> For example the fact that `import std.v1.file` is the same as `import std.file`.

I don't understand this question, can you please rephrase?

> 2. How does `v2` without actual `v2` module binds `v1` ?
> For example `import std.v2.file` is the same as `import std.v1.file`, despite of no physical `std.v2.file` file (to pull v1).

There will be a physical `std.v2.file`. It may only contain aliases and/or public imports.

On Sunday, 31 October 2021 at 01:59:38 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/8309
>
> Destroy!

All I can think of is "Why can't we used a package manager for Phobos?".

-Alex

On Monday, 1 November 2021 at 16:40:42 UTC, H. S. Teoh wrote:
> If classes are not the answer, then what's the alternative?
>
>
> T

How about a sumtype based wrapper?

On Monday, 1 November 2021 at 13:48:08 UTC, Adam D Ruppe wrote:
> I remain skeptical this scheme will work as well when we get into the rest of the changes...

How will IDEs that auto inject import statements work?
Prefer the latest version?

On Monday, 1 November 2021 at 18:12:26 UTC, Ola Fosheim Grøstad wrote:
> How will IDEs that auto inject import statements work?
> Prefer the latest version?

I don't know anything about that, but I would assume that'd work well enough. You should always prefer the newest version in new code.