Purity, @safety, etc., in generic code

Timon Gehr timon.gehr at gmx.ch
Mon Feb 25 08:35:52 PST 2013


On 02/25/2013 05:27 PM, deadalnix wrote:
> On Sunday, 24 February 2013 at 23:09:23 UTC, Timon Gehr wrote:
>> On 02/23/2013 09:28 PM, Steven Schveighoffer wrote:
>>> ...
>>>
>>> But I have not gotten around to pitching it because I need to come up
>>> with a really good solution :)  Walter is so sour on any tail-const
>>> solution from past attempts that it has to be bullet-proof and easy.
>>> ...
>>
>> Just add some form of generics and allow passing type constructors as
>> generic arguments.
>>
>> struct range[@type_constructor c]{
>>     ...
>>     @property c(inout(T)) front() inout { ... }
>>     void popFront() { ... }
>>     bool empty() const { ... }
>> }
>>
>> range![inout] opSlice() inout { ... }
>
> That isn't enough as the range!inout must become range!mutable or
> range!const or whatever after being returned.

The inout resolution of opSlice takes care of that.


More information about the Digitalmars-d mailing list