I've just fixed UFCS for the experimental type function branch
jared771 at gmail.com
Fri Sep 11 15:17:52 UTC 2020
On Friday, 11 September 2020 at 14:54:33 UTC, H. S. Teoh wrote:
> Not necessarily. You can accept the most general type class in
> the sig constraints (or omit it altogether), and introspect in
> the function body.
> To take it a step further: what if you can progressively refine
> the allowed operations on a template argument T within the
> template function body? To use your example of InputRange vs.
> RandomAccessRange: the function declares it accepts InputRange
> because that's the most general class. Then within its function
> body, it tests for RandomAccessRange with a static if, the act
> of which adds random access range operations on T to the
> permitted operations within the static if block. In a
> different static if block you might test for BidirectionalRange
> instead, and that would permit BidirectionalRange operations on
> T within that block (and prohibit RandomAccessRange operations).
> This way, you get *both* DbI and static checking of valid
> operations on template arguments.
I think that's exactly what he is talking about with "type-level"
flow-based typing (kinding? ;-)). If types are just another
value, though, you don't need separate mechanisms for value-level
and type-level flow-based typing.
More information about the Digitalmars-d