On Tue, Aug 18, 2020 at 6:00 PM Frederik Zipp <frederik.z...@gmail.com>
wrote:
> axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um
> 17:44:16 UTC+2:
>
>> I think in the overwhelmingly common case (a type-list being a list of
>> identifiers or short type-constructors like channels or slices), having a
>> line per item takes up a lot of vertical real-estate for little use.
>>
>
> Both options, single line and multi-line, are still available with curly
> braces and semicolons
>
Currently, gofmt normalizes struct and interface declarations to a
multi-line format.
Even if it didn't do that here, the extra {} would be gratuitous - they
serve no purpose in the grammar and add no readability.
The only reason in favor seems to be to then "embed" a new kind of
type-literal. Now, first, I don't think `type` is the right term for that
new declaration - it seems very weird and unexpected to me, to use `type X
type { … }` to declare a sum-type. It should really be `enum`, `sum`,
`anyof`,… or something else making the nature of that type clear (like
`struct` and `interface` already do). We could, of course, use any of those
as a new keyword for type-lists as well, eating the cost of introducing a
new keyword.
So, let's say we change the design to use `anyof` or something for
type-lists instead. And let's say we introduce a new kind of `anyof` type,
so we can view a type-list as an embedding of an `anyof`-literal. That
would still be weird, I believe. You would now have three connected things:
1. `anyof` declarations, only usable as types
2. `interface` declarations containing only methods, usable as constraints
and types
3. `interface` declarations containing methods and type-lists ("embedded
`anyof`s), only usable as constraints
This gives `interface` a very weird standing, IMO. It also seems strange to
only allow the third as constraints, once we've solved the zero-value
issues - I can't think of any logical reason to exclude it, just because it
*also* specifies methods. Allowing them to be used as types and/or allowing
`anyof` to be used as constraints (to resolve the weird special standing of
`interface` in this scenario) OTOH puts us in the situation that there are
multiple equivalent ways to write the same thing. `type X anyof { … }`
would be equivalent to `type X interface { anyof { … } }`.
Really, in that situation, it seems simpler to just remove `anyof`
declarations and simply allow any `interface` declaration to be used as
both a type *and* a constraint. The `anyof` declaration doesn't add any
expressive power. So we might as well avoid the detour and not introduce
`anyof` declarations at all. Which, as a bonus, means we can avoid
introducing the keyword and stay with `type` for type-lists. Which leaves
us in the situation from the design draft - just that we have to add the
ability to use `interface`s with type-lists as types.
In short: I both think a) the syntax is bad, which goes on the contra-list
and b) the reasons to do so are unconvincing, so there isn't anything in
the pro-list. At least as far as I'm concerned.
, but in the multi-line case you do not have to manage trailing commas, and
> the first line containing type(s) is not indented differently than the
> following lines.
>
> --
> 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/b2cfd94c-50d0-48df-b371-b018c08b4a23n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/b2cfd94c-50d0-48df-b371-b018c08b4a23n%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/CAEkBMfGDHPBL_NVCr6J%2B727Feq-i6bweSZcNHGVhdBSQx7gBKA%40mail.gmail.com.
