Thread overview | |||||
---|---|---|---|---|---|
|
September 02, 2020 Annotating SortedRange.empty const: Best way to auto-deduce annotations? | ||||
---|---|---|---|---|
| ||||
Hi, About this issue in Phobos: https://issues.dlang.org/show_bug.cgi?id=21216 SortedRange.empty should be const, .front should be inout Just adding const/inout to SortedRange's methods won't be enough; if we add const/inout here, then many other Phobos ranges need to become const/inout-correct to keep the tests passing. Before I dive deeper into annotating their methods, I would like to verify my assumptions on how template function attribute deduction works: 1) I know that templated functions deduce their own attributes on instantiation. But front()/empty() are non-templated methods within the templated struct SortedRange. Will attribute deduction happen here? 2) Is it sensible/possible to force attribute deduction by declaring empty() in SortedRange as a zero-argument template? I.e.: @property bool empty()() { return this._input.empty; } 3) Should I rather annotate the non-templated SortedRange.empty/.front manually? But with what, then? empty() should probably be const, but it's never @nogc if annotated manually, even if the wrapped range offers empty() @nogc. -- Simon |
September 02, 2020 Re: Annotating SortedRange.empty const: Best way to auto-deduce annotations? | ||||
---|---|---|---|---|
| ||||
Posted in reply to SimonN | On 9/2/20 5:23 PM, SimonN wrote:
> Hi,
>
> About this issue in Phobos:
> https://issues.dlang.org/show_bug.cgi?id=21216
> SortedRange.empty should be const, .front should be inout
>
> Just adding const/inout to SortedRange's methods won't be enough; if we add const/inout here, then many other Phobos ranges need to become const/inout-correct to keep the tests passing. Before I dive deeper into annotating their methods, I would like to verify my assumptions on how template function attribute deduction works:
>
> 1) I know that templated functions deduce their own attributes on instantiation. But front()/empty() are non-templated methods within the templated struct SortedRange. Will attribute deduction happen here?
mutability attributes are not deducted for templates.
wrapping ranges such as SortedRange can't really specify const or inout on their methods via introspection of the underlying range. What they can do is template the `this` parameter. Then if the underlying range supports calling that way, it will work, otherwise it won't.
using `template this` should be compatible with the existing code I would think.
-Steve
|
September 02, 2020 Re: Annotating SortedRange.empty const: Best way to auto-deduce annotations? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Wednesday, 2 September 2020 at 21:40:59 UTC, Steven Schveighoffer wrote: > What they can do is template the `this` parameter. Then if the underlying range supports calling that way, it will work, otherwise it won't. > > using `template this` should be compatible with the existing code I would think. Thanks! I've never looked much into template this -- at first glance, it offers what inout already offers -- but it sounds like the right tool for the job. (inout would straightaway disallow calls to mutable methods.) https://dlang.org/spec/template.html#template_this_parameter I'll experiment with it! -- Simon |
Copyright © 1999-2021 by the D Language Foundation