++Phobos

rikki cattermole rikki at cattermole.co.nz
Wed Oct 16 22:34:00 UTC 2019


On 17/10/2019 11:16 AM, H. S. Teoh wrote:
> On Thu, Oct 17, 2019 at 10:59:11AM +1300, rikki cattermole via Digitalmars-d wrote:
> [...]
>> However my main concern with developing a new version of Phobos is
>> isInputRange and friends will still exist. Unless the language has a
>> better way of describing it e.g. signatures we may as well call it an
>> incremental improvement not a new version.
> 
> What's wrong with isInputRange?
> 
> 
> T
> 

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.


More information about the Digitalmars-d mailing list