Nope nope nope!

# announcements

[karelpeeters]

Nope nope nope!

[pablisco]

Why? Why? Why?

[diego-gomez-olvera]

every other project has a StringUtils or similar class

[diego-gomez-olvera]

IMHO it is better for the developer (and the compiler) to easily know which class/function is being used

[pablisco]

Maybe for the compiler, not sure about the developer... I can't remember the last time I looked at an import in Github or the IDE and said: "ah! that's what we are importing... nice."

[louiscad]

Reproducible builds are important. I don't care having to scroll a bit for imports

[pablisco]

Why would it not be reproducible?

[diego-gomez-olvera]

if a dependency is removed and another is added for a class or function, you would not be aware

[diego-gomez-olvera]

nothing would change on the file

[pablisco]

Which would make refactoring easier, right?

[diego-gomez-olvera]

it would make the visual change smaller, yes

[diego-gomez-olvera]

but also less explicit

[pablisco]

Well, fewer places would require changes, not just visualy

[diego-gomez-olvera]

the new class/function behavior could differ without the developer noticing initially

[pablisco]

But that's the same if a library changes the behaviour of a specific type... not sure that's related with the imports

[diego-gomez-olvera]

by having always imports for non stdlib code, the change will be shown in history

[pablisco]

What I mean is that if the behaviour of a class changes and it's imported the developer will be oblivious to that change too

[diego-gomez-olvera]

yes, but not to the fact that it changed

[pablisco]

If the public API of that type has changed it'll be pretty obvious 😅

[diego-gomez-olvera]

simple example: TextUtils.isGraphic in Android does not check for null (nor is annotated). A 'pure Kotlin' project is converted to be an Android project, and its own version of the method (which checks for null) is dropped in favor of the Android one. It is used in rare scenarios not covered by tests.

[diego-gomez-olvera]

I know that Kotlin has better solutions than that, it is just a made up example

[diego-gomez-olvera]

the fact is that if the public signature does not change the developer will not be aware of the behavioral changes under the hood

[pablisco]

In that scenario, the compiler would complain about ambiguity as it has two functions that have the same name and would have to do either an explicit import or do a typealias that changes the name of the function for that module

[karelpeeters]

And then your build breaks because a dependency adds a new class somewhere.

[karelpeeters]

Do you even spend time dealing with imports? I almost never touch them, I don't even see them, they are automatically hidden by the IDE.

[Shawn]

nobody reads imports

[Shawn]

they stay collapsed and honestly they’ve never added excessive “noise” to my PRs, this is a solution in search of a problem

[Shawn]

also the compiler would constantly complain about ambiguity - how many times have we seen someone ask in #C0922A726 or #C0B8MA7FA about some basic functionality not working as expected and it ending up being that they accidentally imported the wrong TextView or whatever?

[Shawn]

do you use CI or have tests run automatically at some point? Do you want builds to start randomly failing because someone upped a version number and included a transitive dependency that exposes another FooBuilder or whatever and the compiler just now asks you to resolve the ambiguity?

[Shawn]

What on earth would “module-wide import alias configuration” even look like? The name itself makes it sound an order of magnitude more complex and less portable than just qualifying your imports from the get go and letting IntelliJ handle the menial work

[pablisco]

“module-wide import alias configuration” Would be useful on its own as then we don't have to do it on every file that uses that import.
The main noise is on Github, like moving a file to a different package and then marking the PR to have 50 files changed and 100 lines changed for a simple refactor. Ideally Github could have more semantic diffs.
Surely, saying that nobody reads imports is more of an argument for this feature.

[pablisco]

Furthermore, packages are kind of an interop feature in Kotlin... There are way more versatile ways to limit scope (separation of concerns since there is no package private) of code in Kotlin than packages

[gildor]

I would say that make sense to improve code review tools rather than change programming language and get all possible problems with implicit imports