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
13 matches
Mail list logo
