On 05/11/2017 07:19 AM, Steven Schveighoffer wrote:
On 5/11/17 12:11 AM, Nick Sabalausky (Abscissa) wrote:
This is a pointless limitation. What is the benefit of requiring the
author to *not* provide an implementation until the transition period is
over? It runs counter to normal workflow.
The idea (I think) is to have a version of the library that functions
*exactly* like the old version, but helpfully identifies where a future
version will not function properly. This is like @deprecate. You don't
put a @deprecate on a symbol and at the same time remove the symbol's
implementation -- you leave it as it was, and just tag it so the warning
shows up. That's step one.
Yes, I'm aware that's the idea the author had in mind, but that still
doesn't begin to address this:
What is the *benefit* of requiring of requiring the author to *not*
provide an implementation until the transition period is over?
I maintain there is no benefit to that. Drawing a parallel to "how you
do it with deprecated symbols" is not demonstrating a benefit. For that
matter, I see the parallel with deprecated symbols as being "The
deprecation tag goes with an implemented function. Symmetry would imply
that a 'newly added' tag also goes on an implemented function." So the
symmetry arguments goes both ways. But regardless, what we *don't*
usually do is develop functionality *after* first finalizing its name.
That's just silly.
> The point is not to break code without fair warning. This is the
> progression I have in mind:
>
> In Library version 1 (LV1), the function doesn't exist.
> In LV2, [the lib author makes a guess that they're going to write a
function with a particular name and the] function is marked as @future.
> In LV3, the function is implemented and the @future tag is removed.
Fixed step 2 for you.
And yes, that *is* the progression suggested by this DIP, but one of my
key points is: that's a downright silly progression. This is better:
- In Library version 1 (LV1), the function doesn't exist.
- In LV2, the new function is marked as @new_symbol to prevent the
(somehow) TERRIBLE HORRIBLE AWFUL consequence of the new symbol causing
people to be required to toss in a FQN, but there's no harm in STOPPING
people from actually using the new functionality if they request it
unambiguously, now is there? No, there isn't.
- In LV3, the @new_symbol tag is removed.
> The important thing here is that the library writer gives fair warning
> that a breaking change is coming, giving the user time to update his
> code at his convenience.
Or, if the tag is added to the actual implementation then there IS NO
FREAKING BREAKING CHANGE until the @new_func or whatever tag is removed,
but the library user is STILL given fair (albiet useless, imo) warning
that it will be (kinda sorta) broken (with a downright trivial fix) in a
followup release.
> I'd say the need for this tag is going to be very rare,
That's for certain.
> but necessary when it is needed.
I can't even begin to comprehend a situation where a heads-up about a
mere "FQN needed here" qualifies as something remotely as strong as
"necessary". Unless the scenario hinges on the current brokenness of
FQNs, which seriously need to be fixed anyway.
> I don't think there's a definitive
> methodology for deciding when it's needed and when it's not. Would be
> case-by-case.
Sounds like useless cognitive bother on the library author for extremely
minimal (at best) benefit to the library user. Doesn't sound like
sufficient justification for a new language feature to me.
> This is not anti-breakage. Code is going to break. It's just a
> warning that the breaking is coming.
>
It's going out of the way to create and use a new language feature
purely out of fear of a trivial breakage situation. Actual breakage or
not, it's "all breakages are scary and we must bend over backwards
because of them" paranoia, just the same.
