Ian Lance Taylor schrieb am Mittwoch, 19. August 2020 um 00:39:16 UTC+2:
> Yes, but here you are assigning the value struct{}{} to the type S.
> That's not how type arguments work: type arguments are not assigned to
> type parameters. Instead, the body of a generic function or type is
>
On Tue, Aug 18, 2020 at 1:48 PM Frederik Zipp wrote:
>
> Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:
>>
>> What would it mean to permit any type as a constraint?
>
>
> Each type would match exactly the same types it would match in a plain old
> function parameter
Ian Lance Taylor schrieb am Dienstag, 18. August 2020 um 21:26:23 UTC+2:
> What would it mean to permit any type as a constraint?
>
Each type would match exactly the same types it would match in a plain old
function parameter list:
type MyStruct struct{}
func (s MyStruct) M() {}
== Type
On Tue, Aug 18, 2020 at 11:29 AM Frederik Zipp wrote:
>
> The more I think about it the less I understand why type list should reside
> inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
> 2) The idea that only interfaces should be able to act as
On Tue, Aug 18, 2020 at 9:04 PM Frederik Zipp
wrote:
> I'd argue that every type expresses a certain subset of types, not just
> interfaces. For the other types the size of the subset just happens to be 1
> (each containing just itself).
>
You can certainly argue that. Though FTR, conceptually
On Tue, Aug 18, 2020 at 7:38 AM Frederik Zipp wrote:
>
> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it
> was a
axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 20:47:12
UTC+2:
> We already have a way to express "any of a certain subset of types", which
> are interfaces, so using them for constraints is natural.
>
I'd argue that every type expresses a certain subset of types, not just
On Tue, Aug 18, 2020 at 8:29 PM Frederik Zipp
wrote:
> The more I think about it the less I understand why type list should
> reside inside interfaces. I can only think of two reasons:
>
> 1) Avoid a new keyword for type lists.
>
2) The idea that only interfaces should be able to act as
The more I think about it the less I understand why type list should reside
inside interfaces. I can only think of two reasons:
1) Avoid a new keyword for type lists.
2) The idea that only interfaces should be able to act as constraints.
Regarding 2): Why this artificial limitation? Why not
Frederik Zipp schrieb am Dienstag, 18. August 2020 um 19:44:05 UTC+2:
> I agree it is a weird combination. Ideally it would be:
>
> 1. `anyof` declarations containing only types, usable as constraints and
> types
> 2. `interface` declarations containing only methods, usable as constraints
> and
axel.wa...@googlemail.com schrieb am Dienstag, 18. August 2020 um 19:19:32
UTC+2:
> 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
On Tue, Aug 18, 2020 at 6:00 PM Frederik Zipp
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
>>
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
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. Also,
hopefully, almost never would really use them anyway, with basically all
Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:
> I don't think so. The type list in this case is syntactically just an
> identifier list, i.e not a list containing possibly eg. type
> literals/anonymous types.
>
I just looked into the draft design again: If composite types
Jan Mercl schrieb am Dienstag, 18. August 2020 um 16:45:54 UTC+2:
> i.e not a list containing possibly eg. type literals/anonymous types.
>
Yes, I wanted to interpret a type list conceptually as an anonymous type
embedded in an interface.
--
You received this message because you are
On Tue, Aug 18, 2020 at 4:38 PM Frederik Zipp wrote:
> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it
> was a
The draft syntax for type lists is a comma separated list:
type SignedInteger interface {
type int, int8, int16, int32, int64
}
Wouldn't it be more consistent with existing Go syntax regarding types if
it was a semicolon separated list in curly braces?
type SignedInteger
18 matches
Mail list logo
