++Phobos

[Jacob Carlborg]

On Wednesday, 16 October 2019 at 22:34:00 UTC, rikki cattermole 
wrote:

> So these sorts of "functions" are aggregates of behavior and 
> properties that require reading the source code to know fully 
> what it entails.
>
> Yes, aggregates of behavior can be complex, and it does make 
> sense to use "functions" to do it. But the key difference here 
> is if you can describe what most of the behaviors and 
> properties are to the compiler it can produce better error 
> messages but also allow code to be more descriptive. I.e.
>
> /// Docs go here
> signature InputRange(@named ElementType) {
> 	@property {
> 		/// Docs go here
> 		ElementType front();
>
> 		/// Docs go here
> 		bool empty();
> 	}
>
> 	/// Docs go here
> 	void popFront();
> }
>
> void func(T:InputRange)(T myInputRange) {}
>
> The above uses DIP1020 just to make this conversation a little 
> easier to understand (ElementType will be inferred 
> automatically from the implementation).
>
> And because we have described what an input range is in terms 
> of an interface, we can use it as a value typed vtable that yes 
> can work in -betterC.
>
> Something like this should enable us to have better 
> documentation using much simpler looking features without 
> hiding away details in the source code.

Can't we just allow structs to implement interfaces and use 
template specialization? Something like this:

interface InputRange(ElementType)
{
     ElementType front();
     bool empty();
     void popFront();
}

struct Range(E) : InputRange!E
{
     E front() { return E.init; }
     bool empty() { return true; }
     void popFront() { }
}

void foo(T : InputRange!int)(T range) {}

void bar()
{
     InputRange!int a = Range!int.init; // will not compile
}

--
/Jacob Carlborg