++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