On Wednesday, 3 October 2018 at 14:27:42 UTC, Dejan Lekic wrote:
> IDK, I prefer things done in the UNIX way - do one thing and do it right. Compiler should do what its name says - COMPILE, while some other tool should be made for these kind of code checks. The code will compile no matter whether there are some unused imports or not, right?

Sure, the Unix way is a nice philosophy, but let's face the facts:
- Because of (amongst others) CTFE and mixin, D is an incredibly complicated language to reason about (unlike Java or C#)
- There is only one D front-end, and it will likely stay that way for a while
- Any static analysis tool that doesn't only work with a subset of the language must basically re-implement a complete compiler front-end or leverage dmd

Also dmd is currently not following the Unix way by a long shot. You could have separate programs for the optimizer and assembler, like some compilers have. Every stage of compilation could be a separate program, and that would even be beneficial to static analysis tools, but that has other problems too (like changes in the API, worse performance because of text input and output).

Currently we have a package that does everything that requires intricate knowledge of the D language: compiling, documentation generation, profiling, and warning about things like dead code. Also unit-testing is part of the language and the standard library is huge. Warning about unused imports seems like a useful addition to me.

On 09/26/2018 06:00 AM, Anonymouse wrote:
> On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:
>> I'm playing with a branch of DMD that would warn on unused imports:
> 
> Would just like to say that I love the idea and would use it immediately.

Same here. Periodically, my import lists tend to turn into giant outdated blobs of everything ever used by my project. But pruning them is a major involvement involving many, many cycles of pure trial-and-error. I've often wanted a way to say "Hey, just TELL me which imports are unused, so I don't have to spend half the afternoon manually testing them all!"

On Thursday, 4 October 2018 at 18:55:01 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/26/2018 06:00 AM, Anonymouse wrote:
>> On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:
>>> I'm playing with a branch of DMD that would warn on unused imports:
>> 
>> Would just like to say that I love the idea and would use it immediately.
>
> Same here. Periodically, my import lists tend to turn into giant outdated blobs of everything ever used by my project. But pruning them is a major involvement involving many, many cycles of pure trial-and-error. I've often wanted a way to say "Hey, just TELL me which imports are unused, so I don't have to spend half the afternoon manually testing them all!"

Exactly. Even me with my very low usage of D have already been confronted with that. A wall of outdated imports which requires real involvement to clean up.
An optional warning to tell which are not used would be already a good step.

On Wednesday, 3 October 2018 at 17:33:43 UTC, Dennis wrote:
> Sure, the Unix way is a nice philosophy, but let's face the facts:
> - Because of (amongst others) CTFE and mixin, D is an incredibly complicated language to reason about (unlike Java or C#)
> - There is only one D front-end, and it will likely stay that way for a while
> - Any static analysis tool that doesn't only work with a subset of the language must basically re-implement a complete compiler front-end or leverage dmd
>
This is a big point actually. There are several design choices in D that were made for the ease of parsability of the code, for example using !() instead of <> (personally I think <> look much cleaner, but I understand how it's harder to parse).


As for the thread. I think this could work either as a warning or in the compiler. The problem with making it a warning is that people might want to disable the feature once it breaks the build. It's a big pain in Go. Imagine importing a logger, and then putting some log methods int he code. Everything is fine. Then you comment out the log lines just for a moment, and bam, import logger is unnecessary and your build breaks.

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:
> I'm playing with a branch of DMD that would warn on unused imports [...]

Hi, i was searching for such a functionality in D and this thread is the most recent result on google. So, i would like to know if there is progress on the topic?

suggestion: implicit import at same line as using

auto result = std.algorithm:find!blahblah(args);

1) its likes to/same as
import std.algorithm : find; with next using
but usuall it looks ugly:
{
  import one.stuff : some;
  import another.stuff : other;

  then goes some code;
  and then using here;
  so when u delete code - u left imports

2) u can use it for classes too
class Derived : some.module.B:Base { // no need import before

3) usually u import some entity for just one using so when u will delete this using u will delete unnecessary import too. no need separate line for it

easy to implement (imo), good looks as D-stuff, solves problem

On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:
> suggestion: implicit import at same line as using
>
> auto result = std.algorithm:find!blahblah(args);
>

note: colon as separator for module part and other
u can still use ufcs and usual magic
module part just says where to look object or method

On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:
> suggestion: implicit import at same line as using
>
> auto result = std.algorithm:find!blahblah(args);
>

4) and u can use different find methods from diff modules without aliases that adds more stupid lines

On Sunday, 31 January 2021 at 19:22:43 UTC, a11e99z wrote:
> On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:
>> suggestion: implicit import at same line as using
>>
>> auto result = std.algorithm:find!blahblah(args);
>>
>
> note: colon as separator for module part and other
> u can still use ufcs and usual magic
> module part just says where to look object or method

OK, u saw implementation for classes with 2 colons
class Derived : some.module:Base {
its simple sample but can be more difficult that uses colon too.
    at here 1st colon means inheritance

u can implement it as
class Derived : some.module@Base { // @
i dont care
but "inplace import with using" looks more preferably

On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:
> suggestion: implicit import at same line as using
>
> auto result = std.algorithm:find!blahblah(args);

We have that, remember

---
template from(string moduleName)
{
  mixin("import from = " ~ moduleName ~ ";");
}

void main()
{
    from!"std.stdio".writeln("check https://dlang.org/blog/2017/02/13/a-new-import-idiom/");
}
---