Den tisdag 7 juli 2020 kl. 16:45:21 UTC+2 skrev rog:
>
> On Tue, 7 Jul 2020 at 10:36, Tobias Gustafsson <tobias.l...@gmail.com
> <javascript:>> wrote:
>
>> Hi all,
>>
>> Thanks for the response on this subject!
>>
>> Yes, a kind of type switch over generic types is probably what I
>> envision. There is a potentially nice symmetry with the current runtime
>> type switches and type annotations that caught my eye (being aware of the
>> fact that finding false patterns and symmetries may lead you astray...).
>>
>> If we do manage to set the semantics for a type switch over a generic
>> type I'd expect that to also spill over to type assertions over generic
>> types. Perhaps it would also be easier to start with at type assertion to
>> explore the problem space a bit more before heading directly for the type
>> switch.
>>
>
> That's not technically needed AFAICS, given that you can already convert
> to interface{} and then type switch, but it's potentially nice as syntax
> sugar.
>
Not sure I completely understand what you mean by this, what I meant is
basically that I would find it good to be able to do things like this:
var x T // Generic type T
s := x.(string) // s is a string or compile time error
s, ok := x.(string) // s is the string x represents if T is of type string,
// otherwise a zero value string.
// Any code relying on ok to be true can be eliminated
// during compilation if type assertion fails and vice
// versa.
>
>
>> I had not given that much thought into if the type switch should be over
>> the variable or the type parameter itself. Doing it over the type parameter
>> definitely implicates a refinement of the previously set type constraints
>> while doing the switch over the variable could allow a more liberal
>> interpretation where additional types/behaviour is tested for that goes
>> outside of what the type constraints specifies (it becomes a "local" type
>> constraint if you like). For the particular use case I have right now (a
>> specialized hash function) doing it as a refinement of the type constraints
>> is enough.
>>
>
> In my description, there's no assumption that doing it over the type
> parameter implies a refinement of the previously set type constraints. In
> fact it definitely implies otherwise because (for example) if you know that
> a generic type parameter has the known type "string", then it's a loosening
> rather than a tightening of the constraint - you can now do more things
> with values of that type than you could previously.
>
Yes, I realized shortly after sending the mail that it was probably not
what you meant. I misinterpreted type refinement in this context and was
probably also a bit primed by the suggested restrictions for type switches
in the generics draft. Having realized this my (somewhat confusing) comment
about switching over types and variables can also be ignored. Switching
over the type parameter is nice and clean I think.
>
> I think there are plenty of examples in existing code bases where type
>> switches/assertions are used to provide additional functionality for types
>> that implement specific behaviours (http.Pusher/http.ResponseWriter comes
>> to mind for example). Not restricting the type switch to be a refinement of
>> the constraint types would allow for backwards compatible evolution of
>> libraries, etc. to provide additional functionality for types that support
>> it.
>>
>
> Yes, this would indeed be possible with my suggestion above. I quite like
> its symmetry with the way that normal type switches work.
>
> When it comes to exact vs. non exact matches I would have thought that the
>> same rules that apply for todays type switches (eg. first match wins) would
>> be enough but perhaps that is not the case in which case I think the "type"
>> notation introduced above looks good. Ideally I would also like "MyInt" to
>> match both "MyInt" and int with the order of the cases in the type switch
>> deciding which case will be triggered. The compiler or external linters
>> could warn/error on unreachable cases.
>>
>
> I don't think it's sufficient. Consider this program:
> https://go2goplay.golang.org/p/wO0JHIuHH2l. If "string" matches both
> "myString" and "string" itself, then the type checker would allow the
> assignment of a function of type "func(string) uint64" to a function of
> type "func(myString) uint64" with no explicit type conversion, which breaks
> an important safety constraint in the language. Worse, if we let an
> interface type match any concrete type that happens to implement that
> interface, then there's a serious issue because those types probably don't
> have the same shape, so can't be used interchangeably. For example, this
> program would be valid, but isn't possible to compile because io.Stringer
> and string have different representations:
> https://go2goplay.golang.org/p/_uLjQxb-z-b
>
Great examples illustrating the need for something more than bare bones
case by case comparison!
>
> Matching over a list of types/variables seems like a potentially useful
>> thing to do.
>>
>
> Thanks for the feedback.
>
> cheers,
> rog.
>
>
>>
>> Thanks
>> // Tobias
>>
>>
>> Den tisdag 7 juli 2020 kl. 08:35:47 UTC+2 skrev rog:
>>>
>>> How about something like this?
>>>
>>> Type switches
>>>
>>> A *generic type switch* allows a generic function to provide
>>> specialized behaviour based on its type arguments (for example to use a
>>> more efficient implementation for some types).
>>>
>>> A type switch refines the type of a type parameter. Cases match actual
>>> types against the generic type parameter in turn. Within the body of a
>>> case, the named type parameter has the actual type. A single case may not
>>> list more than one type.
>>>
>>> By default, matching is exact: for a case to match, the type parameter
>>> must be exactly the specified type. By wrapping the specified type in a
>>> type qualifier, the matching is not exact, but *matches* the kind of
>>> type instead. For some non-interface type X, type(X) matches any type
>>> with an underlying type of X. When X is an interface type, type(X) matches
>>> any type that implements the interface. Type-list interfaces are allowed.
>>>
>>> func F(type T, U)() {
>>> switch T {
>>> case int:
>>> // T is exactly the type int.
>>> case error:
>>> // T is exactly error, not some type that happens to satisfy
>>> the error inferface.
>>> case type(string):
>>> // T is any type with an underlying type of string
>>> case type(io.ReadCloser):
>>> // T is any type that satisfies the io.ReadCloser interface.
>>> case type(interface{
>>> type int, int64
>>> }):
>>> // T has an underlying type of either int or int64.
>>> case string:
>>> // Compile error: duplicate case (matched by generic(string)
>>> above).
>>> case type(io.Reader):
>>> // Compile error: duplicate case (matched by
>>> generic(io.ReadCloser) above).
>>> case U:
>>> // Both type parameters are exactly the same type.
>>> }
>>> }
>>>
>>>
>>> *Discussion*
>>>
>>> It might be a good idea to allow a type switch to specify a list of
>>> types rather than a single type, so several generic parameters can be
>>> specialized at the same time. For example:
>>>
>>> switch T, U {
>>> case int, string:
>>> }
>>>
>>>
>>> This is syntactically rather more useful than in a normal type switch,
>>> because there's no way to avoid nesting type switches (in a normal type
>>> switch, it's possible to assign the specialized value to another variable
>>> with wider scope, but that's not possible in general with generic type
>>> switches). However, it may be too confusing syntactically with the normal
>>> comma-list in a type switch statement which means "any of these types". A
>>> possible way of avoiding confusion that might be to require brackets:
>>>
>>> switch T, U {
>>> case (int, string):
>>> }
>>>
>>>
>>> The ability to use a concrete type directly in a type(X) case is just
>>> syntax sugar for type(interface{type X}) and could be omitted. It
>>> depends how commonly used this might be.
>>>
>>>
>>> On Tue, 7 Jul 2020 at 04:51, Steven Blenkinsop <stev...@gmail.com>
>>> wrote:
>>>
>>>> On Mon, Jul 6, 2020 at 6:29 PM, roger peppe <rogp...@gmail.com> wrote:
>>>>
>>>>>
>>>>> I've also been playing around in this area. I've been trying something
>>>>> similar to this approach: https://go2goplay.golang.org/p/sHko_EMhJjA
>>>>> But this isn't ideal - note that we lose type safety when assigning
>>>>> back to the generic hash function, because there's no way to let the
>>>>> compiler know that the actual type of the generic type parameter is known
>>>>> at that point.
>>>>>
>>>>> I also noticed an interesting wrinkle to doing a type switch on a
>>>>> value of the type:
>>>>>
>>>>> We can't do this:
>>>>>
>>>>> case Hasher:
>>>>> hi = func(t Hasher) uintptr {
>>>>> return t
>>>>> }
>>>>>
>>>>> because the actual type probably isn't Hasher - it's the actual type,
>>>>> not the interface type.
>>>>>
>>>>> If a type switch on a type argument was implemented (and I definitely
>>>>> support it) we'd have to think carefully about what semantics would be
>>>>> desired in this case - if one of the types is an interface type, would
>>>>> one
>>>>> get the usual interface-subtype rules for matching or not?
>>>>>
>>>>> For the record, I quite like the idea of using a separate syntax for
>>>>> type-based checking:
>>>>>
>>>>> type switch T {
>>>>> case int:
>>>>> case string:
>>>>> }
>>>>>
>>>>> That way, we could use exact-match rules for that construct without
>>>>> risk of confusion with the normal type switch rules, and perhaps the
>>>>> difference might make it clearer that T would change its type inside the
>>>>> body of the switch.
>>>>>
>>>> If the idea is to be able to refine the constraints on a type
>>>> parameter, then you need to be able to match based on "T satisfies
>>>> this interface". If you want to be able to match based on underlying type,
>>>> you could match against e.g. interface { type int }.
>>>>
>>>> I'm not sure how useful matching on a precise type is in this context.
>>>> Interfaces can't express exact type constraints as currently designed, so
>>>> exact type matching can't ever handle all cases. You'd need a really good
>>>> reason to be treating exactly one type out of the set with the same
>>>> underlying type differently in order for it to make sense.
>>>>
>>>> If you needed to, though, you could plausibly do it by:
>>>>
>>>> type switch *T {
>>>> case interface { type *fmt.Stringer }:
>>>> // T has to be the interface type `fmt.Stringer`
>>>> case interface { type *int }:
>>>> // T has to be the specific concrete type `int`
>>>> }
>>>>
>>>> Whether to support the following is what could potentially cause
>>>> confusion:
>>>>
>>>> func F(type T interface { type int })(t T) {
>>>> type switch T {
>>>> case int:
>>>> ...
>>>> }
>>>> }
>>>>
>>>> Someone could plausibly believe this covers all possible cases, when it
>>>> doesn't cover type MyInt int, for example. This could either be
>>>> disallowed or picked up by a lint. Disallowing it would force the above
>>>> workaround syntax using pointer types in interface type lists. This is a
>>>> bit kludgey, but then it probably shouldn't be easier to do the thing
>>>> which
>>>> will more often be wrong than the thing that will more often be right.
>>>>
>>>> The other thing is that interface constraints as currently designed
>>>> don't really lend themselves to refinement in the first place. Sure, if
>>>> you
>>>> have an interface with a type list, you can match on a subset of that type
>>>> list, but you can't ask whether a type "is in this type list *or*
>>>> satisfies
>>>> this interface" or "satisfies at least one interface in this list".
>>>> Easiest
>>>> solution might be to allow comma separated embedded interfaces:
>>>>
>>>> type CustomOrdered(type T) interface {
>>>> Less(T) bool
>>>> }
>>>>
>>>> type AnyOrdered(type T) interface {
>>>> constraints.Ordered, (CustomOrdered(T))
>>>> }
>>>>
>>>> (I should also mention I don't really *like* having to define the above
>>>> interfaces so they have to be applied reflexively to work. The fact that
>>>> it will be done automatically in type parameter lists helps, but it still
>>>> feels wrong to have to do it. I understand that this is to sidestep
>>>> needing to add a second kind of generic type name in interface
>>>> definitions, though.)
>>>>
>>>> --
>> 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 golan...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/9d755182-3844-4a58-962e-cc332f1a69cdo%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/9d755182-3844-4a58-962e-cc332f1a69cdo%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/fdf32c65-7b8d-4218-a35e-971839f3abb1o%40googlegroups.com.
