The proposal says:
To ensure backwards compatibility with existing code, the new semantics
will only apply in packages contained in modules that declare go 1.22 or
later in their go.mod files. This per-module decision provides developer
control of a gradual update to the new semantics throughout a codebase
I think this is not *safe*, since the `go` directive is often not
explicitly chosen by the programmer. An example is when using `go mod
init`; I suspect that most users will simply keep the current version.
This is probably not an issue with `loopvar-preview` but it may prevent
other language changes.
As an example, suppose someone want to implement support for
`error-propagation` (as done by Zig). In this case the user **must**
explicitly declare that he want this feature, so that it (probably) does
not count as breaking the Go1 compatibility.
A possible solution is to add a new `feature` field to `go.mod`. As an
example:
```go
feature (
loopvar
error-propagation
)
```
Regards
Manlio Perillo
--
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/9f96ba8a-1a2d-4914-875a-c8c65ed7f4een%40googlegroups.com.
