I use dscanner to lint my code and find it helpful.

However, in GtkD there are several functions which take ref args, and these confuse dscanner.

For example:

        uint kv;
        event.getKeyval(kv); // ref arg is updated here

dscanner incorrectly (but understandably) reports:

    Variable kv is never modified and could have been declared const or immutable.

If D allowed the _optional_ use of ref at the call site:

        uint kv;
        event.getKeyval(ref kv);

Then this would not only help dscanner, but also make it clear to programmers that the argument could be modified.

(This is done in Rust with f(&mut arg), and I certainly find it helpful.)

On 2020-02-23 10:03, mark wrote:

> Then this would not only help dscanner, but also make it clear to programmers that the argument could be modified.

It's not necessary for dscanner. It should look at the signature of `getKeyval` to see that it takes an argument by `ref`.

-- 
/Jacob Carlborg

On Sunday, 23 February 2020 at 09:35:30 UTC, Jacob Carlborg wrote:
> On 2020-02-23 10:03, mark wrote:
>
>> Then this would not only help dscanner, but also make it clear to programmers that the argument could be modified.
>
> It's not necessary for dscanner. It should look at the signature of `getKeyval` to see that it takes an argument by `ref`.

Just realised that the arg is 'out' not 'ref'; don't know if that makes a difference to dscanner. Anyway, I've made a bug report: https://github.com/dlang-community/D-Scanner/issues/793

On 2020-02-23 13:28, mark wrote:

> Just realised that the arg is 'out' not 'ref'; don't know if that makes a difference to dscanner. Anyway, I've made a bug report: https://github.com/dlang-community/D-Scanner/issues/793

Same idea applies. dscanner should look at the signature. In the case of `out`, the compiler will also set the value of the argument to its .init value before calling the function.

-- 
/Jacob Carlborg

On Sunday, 23 February 2020 at 09:03:56 UTC, mark wrote:
> Then this would not only help dscanner, but also make it clear to programmers that the argument could be modified.
>
> (This is done in Rust with f(&mut arg), and I certainly find it helpful.)

C# also does it, and uses exactly the same keyword as D:

> To use a ref parameter, both the method definition and the calling method must explicitly use the ref keyword, as shown in the following example.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref

Making it mandatory in D would cause code breakage and hamper generic code, but like you suggest, making it optional is an interesting idea. It can also enforce that something is actually passed by ref to avoid accidental copies, which currently requires manual checking. For example in std.format:

> // force toString to take parameters by ref
> static assert(!__traits(compiles, val.toString(s, FormatSpec!Char())));
> static assert(!__traits(compiles, val.toString(S(), f)));}

https://github.com/dlang/phobos/blob/fee0697a8328dc22258cf09753f39ad5984015db/std/format.d#L3887

On Sunday, 23 February 2020 at 12:28:41 UTC, mark wrote:
> On Sunday, 23 February 2020 at 09:35:30 UTC, Jacob Carlborg wrote:
>> On 2020-02-23 10:03, mark wrote:
>>
>>> Then this would not only help dscanner, but also make it clear to programmers that the argument could be modified.
>>
>> It's not necessary for dscanner. It should look at the signature of `getKeyval` to see that it takes an argument by `ref`.
>
> Just realised that the arg is 'out' not 'ref'; don't know if that makes a difference to dscanner. Anyway, I've made a bug report: https://github.com/dlang-community/D-Scanner/issues/793

This like
https://github.com/dlang-community/D-Scanner/issues/366 or
https://github.com/dlang-community/D-Scanner/issues/298, so a false positive due to limlitations.

D-Scanner:
- only works at the module level (i.e cant see declaration from an import) ;
- does not perform regular semantic (even not the ones done for DCD) ;

People who care should just start developing a new linter based on DMD as a library.
It's pretty clear (IMO) that these problems will never be fixed.