We have a standard linter, only it doesn't use semantic analysis which is what would be required for this.

But yes, dmd-fe should be used in tools like dscanner, dfmt and dcd.

On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:
> I was just thinking, if we had a standard linter, it could solve many issues without bloating the language, since the compiler exists as a library it should not be too difficult to maintain either.
>
> This way we can both keep the cake and eat it.

I could not disagree more.

'classes' and 'information hiding' are 'entangled'.

I've seen many arguments against adding private(this), but no argument (that can be taken seriously), that you shouldn't be able to apply the 'information hiding' principle to a class.

In D, you're told you can do this by putting the class it's own module.

My argument, is that this principle is so tightly entangled with the class concept, that it should be availabe to do with the class type itself.

I think, in principle at least, my argument is a stronger argument, than the one-class-to-a-module argument.

But why you would want to bring a linter in to solve this, puzzles me even more than a language that supports classes, but doesn't having a means (an option) to apply the information hiding principle *within* the class type itself.

In terms of the ever increasing move towards being able to improve the provability of your code, then yes, a linter will have to come into play.

On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:
> I was just thinking, if we had a standard linter, it could solve many issues without bloating the language, since the compiler exists as a library it should not be too difficult to maintain either.
>
> This way we can both keep the cake and eat it.

I'm curious how a linter would have helped me here
(see the comment I had to make ***to myself** in the unittest section)

// ---
module test;

class unsafeVector
{
  private:
    size_t *elem;
    immutable size_t sz;

  public:
    this(size_t s)
    {
        elem = cast(size_t*)new size_t[s];
        sz = s;
    }

    auto ref opIndex(size_t i)
    {
        return elem[i];
    }

    auto ref opSlice(size_t start, size_t end)
    {
        return elem[start .. end];
    }

    auto ref opDollar()
    {
        return sz;
    }

    auto size()
    {
        return sz;
    }
}

// compile with: -unittest -main
unittest
{
    import std;

    unsafeVector v = new unsafeVector(5);

    // Initialise each element with a different value.
    // NOTE TO SELF: Be sure to use the public interface here.
    // Don't accidently use v.sz like I did intially.
    for (int i = 0; i < v.size(); i++)
    {
        v[i] = i+1;
    }

    assert(v[0..3] == [1,2,3] );
    assert(v[0..$] == [1,2,3,4,5]);
    assert(v[$-1] == 5);

    v[2] = 999;
    assert(v[2] == 999);
}

//-----

On Tuesday, 28 June 2022 at 03:52:08 UTC, forkit wrote:
> On Monday, 27 June 2022 at 20:23:26 UTC, Daniel N wrote:
>> I was just thinking, if we had a standard linter, it could solve many issues without bloating the language, since the compiler exists as a library it should not be too difficult to maintain either.
>>
>> This way we can both keep the cake and eat it.
>
> I'm curious how a linter would have helped me here
> (see the comment I had to make ***to myself** in the unittest section)
>

>     // Don't accidently use v.sz like I did intially.
>     for (int i = 0; i < v.size(); i++)

dmd-fe would have told you don't use 'sz' as it is private.