Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A general purpose defaulting annotation, like @Default(NotNull.class) #5

Closed
dzharkov opened this issue Nov 26, 2018 · 8 comments
Closed
Labels
new-feature Adding something entirely new for users, not improving what's there

Comments

@dzharkov
Copy link
Collaborator

The question was initially asked by @kevin1e100:

More generic defaulting annotation, e.g., @Default(NotNull.class)? This might be handy in particular if we see other annotations unrelated to nullness being added later

@dzharkov
Copy link
Collaborator Author

Comments from the document:

[@amaembo] An my experience says that nothing except NotNullness worth declaring on a class/package. Well, I can imagine probably something like Unmodifiable, but I really doubt. Anything else?

@kevinb9n
Copy link
Collaborator

I know of only two other possible uses for this (and let's NOT debate their inclusion in the project here and now; they are just "potential"):

"Caller must use return value of this method"
"Parameter names are exported (so you're allowed to depend on them from e.g. Kotlin)"

But in both of these cases, I don't see why we couldn't just use the same annotation that we use for a single method at the wider scopes.

So I would suggest we plan on a special-purpose annotation for "default not null".

@kevinb9n
Copy link
Collaborator

kevinb9n commented May 1, 2019

I'm still going to leave the door open here. There are other examples, like "Caller must close any AutoCloseables returned from this package/class", that I think will make sense.

It occurred to me belatedly that defaults are useful for two different reasons:

  1. Lessening annotation burden
  2. So that new code gets the preferred behavior automatically

I wasn't thinking of #2 enough before.

My main concern about @Default(NotNull.class) and so forth is that it would only work for parameterless annotations, which might push our designs more toward parameterless annotations than they shouldbe?

@kevinb9n
Copy link
Collaborator

kevinb9n commented Jun 17, 2019

@Default may be an insufficient name - need something like @DefaultWithin or @DefaultForUsages

@kevinb9n
Copy link
Collaborator

kevinb9n commented Jun 26, 2019

Another problem with @Default(NotNull.class) is that there's now TWO classes a user needs to import in every file (both of which are highly likely to be used only once). I think that will make them even more cranky than one.

@kevinb9n kevinb9n changed the title More generic defaulting annotation A general purpose defaulting annotation, like @Default(NotNull.class) Oct 10, 2019
@kevinb9n
Copy link
Collaborator

Another possible approach here is to have @DefaultNotNull but to have that class annotated as @DefaultAnnotationFor(NotNull.class) and have that linkage convey the semantics.

@cpovirk
Copy link
Collaborator

cpovirk commented Dec 4, 2019

Given that we dismissed @DefaultNullable for its added complexity (#41), it seems likely that we'd dismiss this proposal, too?

@kevinb9n
Copy link
Collaborator

kevinb9n commented Dec 5, 2019

Yeah, and nothing ever gelled around this idea.

@kevinb9n kevinb9n closed this as completed Dec 5, 2019
@kevinb9n kevinb9n added the new-feature Adding something entirely new for users, not improving what's there label Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-feature Adding something entirely new for users, not improving what's there
Projects
None yet
Development

No branches or pull requests

3 participants