I am replying mostly to https://resea rch.swtch.com/vgo-import article.
It is proposed that "moauth" author should do double work, even if his code
works absolutely fine with either verion of oauth. This viral effect will
be causing chain reaction and a lot of people will be creating unnecessary
> Short version to just get a taste:
>
> type Time struct {
> Err error
> *time.Time
> }
>
> func now(pass bool) Time {
> if !pass {
> return Time{Err: errors.New("not now")}
>
> That's why I've used *time.Time, not time.Time - if you try to use it when
> t.Err is set you'll get panic because of nil value.
>
>
>
Runtime checks doesn't count :) Compiler still allowed you to use value,
when error was set.
--
You received this message because you are subscribed to th
gopkg.in already "redirects" different import paths to different branches
in your repo. You then use correct module name in go.mod in each branch and
it all just works.
As for "major version inside import branches" , it seems to be a cornerstone
of whole vgo proposal, so I doubt it is up for d
In the light of recent vgo discussion, I was thinking about what would be
major change or and what wouldn't.
Wanted to ask Goers, in the new better post vgo world, if you changed
exported function argument from *int* to *float*, would you release your
package as v2?
--
You received this m
>
> Yes, definitely. The only way that *wouldn't* break a reverse dependencies
> code is if they'd only use the function with number-literals. Which is
> sufficiently unusual to be put very firmly on the "breaking change" side of
> things.
>
And even then it technically breaks, because range o
