4 ms·
> Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such too
by cakoose 11y ago
> Your method doesn't follow the same format as the rest of Go's syntax (eg comma delimited lists) which could break any 3rd party pre-parsers or other such tooling. So there's the potential break backwards compatibility there.
The new slicing syntax could have broken 3rd party pre-parsers or other tooling. Yet that change was considered backwards-compatible.
- laumars 11y agoIt could have done, but there's fewer tooling that parse slices (particularly at that point in time) than there are which parse import strings (there's lots and lots of tools that already do that!). However the other key point is one I made earlier: slices already support a number of optional parameters so the language semantics didn't change even if the syntax of slices were expanded. adding 1 additional optional parameter to a property that already supports multiple optional parameters really isn't comparable to the import example which had a list of values represented in a new and completely non-idiomatic way (Ie initially without punctuation and then nested inside a string. Nothing else in Go follows that pattern, let alone the import strings already).