Basically every change to any exported API is a breaking change
<https://blog.merovius.de/posts/2015-07-29-backwards-compatibility-in-go/>,
strictly speaking. For this case, a user might do
var f func() = pkg.Bar
Which would fail to compile if `pkg.Bar` gains variadic arguments. Similar
constructs can be done for any change to the type of any identifier.
That's why the Go 1 compatibility promise (and any notion of compatibility)
is essentially reduced to explicitly list the changes it considers allowed.
Best I know, it's
- Adding a method to a type
- Adding a field to a struct
- Adding a new exported identifier
However, by extension, you can technically apply whatever compatibility
promises you like. It is not entirely uncommon to document that you reserve
the right to make certain changes - you could very well document that you
would not consider adding variadic parameters a breaking change, so users
of your package should not assume it doesn't happen and avoid constructs as
above (basically, storing `pkg.Bar` in any variable, unless it uses a short
variable declaration and the type of that variable doesn't matter).
On Tue, May 3, 2022 at 9:28 PM Changkun Ou <m...@changkun.de> wrote:
> Hi gophers,
>
> I wonder how the Go project defines a breaking change, specifically for
> the case where we have an existing API but want to add ... to its parameter
> list for customizations.
>
> For instance, we have an API:
>
> package foo
> func Bar() {}
>
> And the current code uses this function as:
>
> foo.Bar()
>
> Now, we added a ... to the Bar() and having a new function signature:
>
> func Bar(args ...any) {}
>
> Technically, the language allows the existing users to continue to work:
>
> foo.Bar() // still OK.
>
> As long as we don't change how Bar() behaves by default, it seems that the
> code that previously used foo.Bar() is still considered valid and not
> breaking. Is introducing this type of API signature change considered a
> breaking change in the standard library?
> What if we propose API changes like this to the existing standard library,
> will it be considered differently compared to an actual breaking change?
>
> Thanks!
> Changkun
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9e9c58f0-7a79-4c43-9389-72f8d2954080n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/9e9c58f0-7a79-4c43-9389-72f8d2954080n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG4jbbvmRMoEOAs0VN5tAhJUEQeWXR68kgeuzsYCJSVoQ%40mail.gmail.com.
