On 9/13/22 10:08, Paul Backus wrote:
> Here's my attempt, covering all the attributes found under
> [`MemberFunctionAttribute`][1] in the language spec:
>
> |Attribute|Affects |Inferred?|
> |-||-|
> |nothrow |Function|Yes |
> |pure |Function|Yes |
> |@nogc
On Tuesday, 13 September 2022 at 14:16:39 UTC, Ali Çehreli wrote:
On 9/12/22 09:39, Paul Backus wrote:
> Yes. Except for `@trusted`, explicit attributes on template
code are a
> smell.
Except for 'const' as well because some templates are member
functions. And 'const' on a member function cann
On 9/12/22 09:39, Paul Backus wrote:
> Yes. Except for `@trusted`, explicit attributes on template code are a
> smell.
Except for 'const' as well because some templates are member functions.
And 'const' on a member function cannot be left to inference because it
happens to be a part of the typ
On Monday, 12 September 2022 at 16:39:14 UTC, Paul Backus wrote:
[snip]
Yes. Except for `@trusted`, explicit attributes on template
code are a smell.
[snip]
If I can be 100% sure that something will always be
@safe/nothrow/pure/@nogc, then I might consider marking them as
such. For instan
On Mon, Sep 12, 2022 at 02:29:58PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> If your intent is to *enforce* pure functions only, then that's what
> you do. If your intent instead is to ensure that given proper
> parameters, the function will be pure, then the answer is to
On 9/12/22 11:29, Steven Schveighoffer wrote:
> So you are thinking about this the wrong way I believe.
Clearly.
> When you put `pure` on a template function, you are saying "only
> instantiations where this function can be pure are allowed".
Makes sense. I was trying to put as many attributes
On 9/12/22 1:08 PM, Ali Çehreli wrote:
On 9/12/22 09:48, H. S. Teoh wrote:
>> @nogc nothrow pure @safe
>> unittest
>> {
>> // ...
>> }
>>
>> No, it isn't because unless my unittest code is impure, I can't catch
>> my incorrect 'pure' etc. on my member functions.
> [...]
>
> Sure
On 9/12/22 10:29, H. S. Teoh wrote:
write a unittest where you instantiate Foo with a
deliberately-impure type
Yes. A current on-topic thread on the difficulties of covering all
corner cases:
https://forum.dlang.org/thread/dmnfdqiplbldxkecp...@forum.dlang.org
Ali
On Mon, Sep 12, 2022 at 10:08:29AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> What I meant was
>
> - if I put 'pure' etc. on my templatized code,
>
> - and then tested with a 'pure' unittest,
>
> I wouldn't know that the gratuitous use of my 'pure' on the member
> function was wr
On 9/12/22 09:48, H. S. Teoh wrote:
>> @nogc nothrow pure @safe
>> unittest
>> {
>> // ...
>> }
>>
>> No, it isn't because unless my unittest code is impure, I can't catch
>> my incorrect 'pure' etc. on my member functions.
> [...]
>
> Sure you can. The `pure unittest` code obviously must i
On Mon, Sep 12, 2022 at 09:14:42AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[...]
> struct Foo(R) {
> R r;
> int i;
>
> bool empty() @nogc nothrow pure @safe scope {
> return r.empty;
> }
>
> auto front() @nogc nothrow pure @safe scope {
> return r.fr
On 9/12/22 12:14 PM, Ali Çehreli wrote:
What are best practices here?
attributes such as `pure`, `@nogc`, `nothrow`, `@safe` should all be
left to inference. Either the function can do those attributes, or it
cannot.
attributes such as `const` or `inout` are different -- these are *not*
in
On Monday, 12 September 2022 at 16:14:42 UTC, Ali Çehreli wrote:
Is this accurate: Because Foo is a template, it should not put
any attribute on member functions? Or only member functions
that use a member that depends on a template parameter? And
non-members that are templates?
Yes. Except f
The following range Foo is trying to be helpful by adding as many
attributes as it can ('const' is missing because ranges cannot be
'const' because at least popFront() needs to be mutable):
import std.algorithm;
struct Foo(R) {
R r;
int i;
bool empty() @nogc nothrow pure @safe sco
14 matches
Mail list logo
