Hey folks :wave: Working on a library and a new m...

# library-development

[Oscar]

Hey folks 👋
Working on a library and a new major version is coming up. I'm deprecating a bunch of things with @Deprecated, but this obviously gives warnings on all usages of the given classes. The aim is to warn users to not use these classes, but internally I have to keep support for them. Is there a way to suppress deprecation warnings of my own code without suppressing deprecations from let's say other libraries etc?

[Dmitry Khalanskiy [JB]]

@Suppress("DEPRECATION") or @Suppress("DEPRECATION_ERROR"), depending on the DeprecationLevel.

[mbonnin]

That works the same for all declarations.

[mbonnin]

So if you suppress it in a file (imports are specifically problematic) you lose the ability to detect all the other deprecations

[Dmitry Khalanskiy [JB]]

Ah, got it. Sorry, I misread the question.

[mbonnin]

I've been wondering about this too for a while but never really formalized the question

[mbonnin]

We have @file:Suppress("DEPRECATION") in a bunch of files because we still need to use those symbols internally but the end result is that we effectgivelly ignore all deprecations in those files

[mbonnin]

https://youtrack.jetbrains.com/issue/KT-30155/Allow-to-suppress-DEPRECATION-for-single-import would help a lot already as we could be a lor more focused about the suppressions

[Dmitry Khalanskiy [JB]]

No, I don't think there's anything in the language that can help with that. We are just `Suppress`ing everything in our libraries. The only viable option today is to restructure the code to, say, only refer to these entities in isolated places.

[Dmitry Khalanskiy [JB]]

As for imports: are there any downsides to using star imports for first-party packages?

[bod]

instead of * imports you can use fully qualified names (but yeah, not cool either)

[Oscar]

Being able to suppress imports would be a great thing already, but it would still require quite some manual effort to suppress everything. Just thinking out loud: scoping deprecations would solve all of these issues at once. Somehow you would specify this deprecation is only to warn outside of your library and that would be all.
Kinda like Android's RestrictTo.Scope, but inverted I guess

[mbonnin]

are there any downsides to using star imports for first-party packages?

Mainly that it requires special formatting rules if not the star imports end up being removed I think.
Have never really dug into this but I've seen it before

[Oscar]

Thanks for all the swift replies btw! For now I think I will suppress as much as possible without suppressing whole files

[mbonnin]

I'd be happy with a compiler argument:
-Xignore-deprecation-for=com.example1,comp.example2,...

[mbonnin]

Feels very specific but maybe that'd do it?

[Oscar]

That would also do the trick ➕