++Phobos

[Meta]

On Saturday, 19 October 2019 at 02:57:33 UTC, rikki cattermole 
wrote:
> So my problem is with the struct itself knowing about the 
> "interface" (whatever definition you use doesn't matter).
>
> Currently we are good with isInputRange. Because the 
> implementation of an input range does not need to know about 
> that "function" in any form including the InputRange class 
> interface.
>
> DbI works at the usage site, not at the declaration site of 
> whatever is getting passed in. Its about limiting and adapting 
> the user code to fit the types being passed in.
>
> So it doesn't matter if you inherit a class interface from a 
> struct, or use a UDA, you are telling the type about the 
> interface.
>
> I.e.
>
> auto map(Args)(Args arg) {
> 	static struct Map {
> 		@property {
> 			Something front() @nogc { ... }
> 			bool empty() @nogc { ... }
> 		}
>
> 		void popFront() @nogc { ... }
> 	}
>
> 	return Map(arg);
> }
>
> void myFunc(IR)(IR input) { ... }
>
>
>
> What we want to do, is restrict the template parameter (IR) to 
> an input range. But the input range interface that is being 
> used (e.g. a variant like @nogc) may not have been known to the 
> map function (doesn't matter why) and there is no reason for it 
> to have known about it at all.

I assume you're describing ML's signatures, which I'm not 
familiar with, but I see your problem with structs implementing 
interfaces. However, I don't see how `implements` has this same 
problem. It's all ad hoc; the "implementing" struct never has to 
know that the InputRange interface exists at all.

> There may also be other restricting factors like the 
> ElementType. Now for very simple cases this can be done as part 
> of a template parameter, and more complex ones can go into 
> template constraints like we do now (since its a more advanced 
> use case).
>
> Thing is, if all we want to do is to check if its an input 
> range, we shouldn't need to use template constraints. They are 
> a very advanced language feature involving CTFE and language 
> based traits.
>
> So if we were to look into rewriting Phobos, shouldn't we make 
> something that is common and fairly advanced, into something 
> that is simple to understand? Because that is what I'm arguing 
> for.

I agree, but the only comparable language that tried to solve 
this problem is C++, and they ended up with a real monster of a 
feature. Rust has `impl <trait>`, but it has the same problem as 
interfaces in that it's not ad hoc.

> Also:
>
> auto:InputRange map(Args)(Args arg) { .. }
>
> A function that returns a value whose type conforms to the 
> InputRange specification. This would significantly improve the 
> documentation (as it cannot be done right now and people have 
> tried to find a solution).

Yes, I agree that's a major weakness both for template 
constraints and Atila's concepts library.