You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now diff can return null, but i'd argue that in some situations it's not desirable and people will write something like diff { } ?: defaultValue
But it's not that obvious that diff returns null at all and personally i find out about it only after my code explodes
So, i think diff should have value parameter default and return non-null, and then we introduce a special version diffOrNull
It can even be nicely deprecated, as we add a new parameter, so we don't silently break anything
The text was updated successfully, but these errors were encountered:
koperagen
changed the title
Consider change "diff" to "diff" and "diffOrNull"
Consider changing "diff" to "diff" and "diffOrNull"
Apr 4, 2023
I want to move this to backlog, because deprecation works really strange for this one and it needs to be fixed on the IDE side . I think this improvement without proper deprecation will bring more harm than use
I don't think that's much of an issue. I face the same with some of my functions in the Selection DSL. This auto-generated replacement code can be shortened back to a lambda using IDE hints anyways, and for people using other IDEs, where ReplaceWith doesn't even work, they have to fix the deprecations manually anyways.
Right now diff can return null, but i'd argue that in some situations it's not desirable and people will write something like
diff { } ?: defaultValue
But it's not that obvious that diff returns null at all and personally i find out about it only after my code explodes
So, i think diff should have value parameter
default
and return non-null, and then we introduce a special versiondiffOrNull
It can even be nicely deprecated, as we add a new parameter, so we don't silently break anything
The text was updated successfully, but these errors were encountered: