I've just fixed UFCS for the experimental type function branch

Meta 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.
>
>
> T

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 mailing list