Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: spec: non-empty interface type for multiple case in type switch #460

Closed
krasin opened this issue Dec 24, 2009 · 11 comments
Closed
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Milestone

Comments

@krasin
Copy link

krasin commented Dec 24, 2009

Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
Try to compile attached file. It will fail with:
main.go:13: v.IsNil undefined (type reflect.Value has no field IsNil)

What is the expected output? What do you see instead?
It would be nice if it is compilable. The core of example is the switch:

var a reflect.Value
switch v := a.(type) {
case *reflect.InterfaceValue,
        *reflect.PtrValue:
        if v.IsNil() {
                fmt.Printf("null")
        }
}
Both reflect.InterfaceValue and reflect.PtrValue has IsNil method but if 
compiler sees the multiple type case, it suppose that v is just 
reflect.Value and could not find IsNil method.

What is your $GOOS?  $GOARCH?
linux, amd64

Which revision are you using?  (hg identify)

affe0f093696+ tip

Please provide any additional information below.
This issue was discussed during review of 
http://golang.org/cl/179125 with Russ Cox.

Attachments:

  1. main.go (203 bytes)
@rsc
Copy link
Contributor

rsc commented Dec 28, 2009

Comment 1:

Labels changed: added languagechange.

Owner changed to g...@golang.org.

Status changed to LongTerm.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2011

Comment 2:

Labels changed: added priority-later.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 4:

Labels changed: added go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Dec 10, 2012

Comment 5:

Labels changed: added size-xl.

@robpike
Copy link
Contributor

robpike commented Mar 7, 2013

Comment 6:

Labels changed: removed go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 7:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 9:

Labels changed: added repo-main.

@iwdgo
Copy link
Contributor

iwdgo commented Jun 27, 2016

Adding code example

package main

import "fmt"

func main() {
    var v uint8 = 0
    var t interface{} = v

    fmt.Printf("v: %T %T", v, &v)
    fmt.Println()
    fmt.Printf("t: %T %T", t, &t)
    fmt.Println()
    switch t := t.(type) {
    case int8, uint8:
        fmt.Printf("BUG : %T %T", t, &t)
        fmt.Println()
    }
    switch t := t.(type) {
    case uint8:
        fmt.Printf("Correct : %T %T", t, &t)
    case int8:
        fmt.Printf("Doesn't display : %T %T", t, &t)
        fmt.Println()
    default:
        fmt.Println("Won't print")
    }
}

Output
v: uint8 *uint8
t: uint8 *interface {}
BUG : uint8 *interface {}
Correct : uint8 *uint8

@rsc rsc changed the title spec: non-empty interface type for multiple case in type switch proposal: spec: non-empty interface type for multiple case in type switch Jun 20, 2017
@rsc rsc added the v2 A language change or incompatible library change label Jun 20, 2017
@ianlancetaylor
Copy link
Contributor

@CostaOnGit I'm sorry, I don't understand your example. Given two different cases, what else could the type be? Are you suggesting that we should implicitly copy the code for each case?

@ianlancetaylor
Copy link
Contributor

This suggestion seems to imply one of

  1. copying the case code for each type, or
  2. if all the cases are interface types, constructing the intersection of the interface types and using that as the type for the case, or
  3. for any type, constructing a new interface type that is the intersection of all the methods of the types in the case.

None of these seem like likely changes to the language. I'm going to close this. If you disagree, please comment. Thanks.

@golang golang locked and limited conversation to collaborators Nov 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

7 participants