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: Go 2: spec: switch case over range #64683

Closed
4 tasks
Goclipse27 opened this issue Dec 12, 2023 · 8 comments
Closed
4 tasks

proposal: Go 2: spec: switch case over range #64683

Goclipse27 opened this issue Dec 12, 2023 · 8 comments
Labels
LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Milestone

Comments

@Goclipse27
Copy link
Contributor

Goclipse27 commented Dec 12, 2023

Go Programming Experience

Intermediate

Other Languages Experience

Java(Past), Python(Past)

Related Idea

  • Has this idea, or one like it, been proposed before?
  • Does this affect error handling?
  • Is this about generics?
  • Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

I don't know

Does this affect error handling?

No

Is this about generics?

No , But can be handled along with generics

Proposal

When we iterate over a range and if we had to do multiple values check on switch case that looks similar to if else statement conditional check as switch statement doesn't accommodate that.

For below Example

	a := &[]struct {
		Month string
		year  int
	}{{"jan", 2000}, {"feb", 2000}, {"jan", 2023}}

	for _, cal := range *a {
		switch {
		case cal.year == 2000 && cal.Month == "jan":
			fmt.Println("1 jan 2000")
		case cal.year == 2000:
			fmt.Printf("Different Month %v 2000 \n", cal.Month)

		default:
			fmt.Println("Not on my watch")
		}
	}

I didn't write if else condition for this as we all know how to do that.

How about we have something like this in go as we iterate over all range data and a switch case for it

	switch _, cal := range *a; cal.date,cal.year,cal.Month{
           case 2000,"jan":
		fmt.Println("1 jan 200")
	   case 2000, _:
		fmt.Println("Other months in 2000")
	   default:
		fmt.Println("Not on my watch")

This can be extended to non range multiple declarations, accommodate different expressions, includes type as well and for generics.

Language Spec Changes

This changes switch statements.

Informal Change

No response

Is this change backward compatible?

Yes

Orthogonality: How does this change interact or overlap with existing features?

This brings in multiple values check against case statement

Would this change make Go easier or harder to learn, and why?

Easy

Cost Description

No Cost

Changes to Go ToolChain

golang language error check static and other.

Performance Costs

Don't know

Prototype

No response

@Goclipse27 Goclipse27 added LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change labels Dec 12, 2023
@gopherbot gopherbot added this to the Proposal milestone Dec 12, 2023
@seankhliao
Copy link
Member

as far as i can tell, this is just to save you 2 lines of code, but make one very long line that's not easy to read

@Goclipse27
Copy link
Contributor Author

Goclipse27 commented Dec 12, 2023

@seankhliao no intention to cut the lines. If you logically speak, i have one value , say I check a day, i use switch case but if i have to have multiple values check like day, month , year, time under same object - that is still a comparison too why not use simple switch case(multiple values) rather involving conditional operators?

This confines more saying my cases are only on these variables.

Ofcourse this may not work where more conditional cases to be written.

@seankhliao
Copy link
Member

we declined multi value switch in #40353

@Goclipse27
Copy link
Contributor Author

Surprised to see like thoughts and example were also same date, year and month 😀.

Had this thought for a different lang long ago , which had limited switch case back then.

I feel this is good fit to consider given consuming multiple return values in switch case.

@adonovan
Copy link
Member

adonovan commented Dec 20, 2023

This seems like a half-baked tuple with half-baked pattern matching. A fully baked tuple with fully baked pattern matching would let you say:

for _ cal := range *a {
    switch (cal.date, cal.year, cal.month) {
      case (_, 2000, "jan"): ...
    }
}

but we have recently turned down a number of proposals for both tuples (#32941) and pattern matching (e.g. #44022), so any new proposal should address their shortcomings explicitly, and in detail.

@findleyr
Copy link
Contributor

Per the rationale in #64683 (comment), this is a likely decline. Leaving open for four weeks for final comments.

@Goclipse27
Copy link
Contributor Author

Goclipse27 commented Jan 24, 2024

@adonovan - I am currently not leaning to introduce new type tuples as I agree on some of these - #64457 @griesemer . However I like packing and unpacking seems relevant and distinct on its purpose
#64457 (comment)
#64613 (comment) @robpike

Having that said, Here also I am trying similar kind though it reduces a line, my thought is to make more multiple values pattern matching. Even the above unpacking will fit into that scenario @urandom

cal...

for _ cal := range *a {
    switch (cal...) {
      case _, 2000, "jan": ...
    }
}

Another example here outside of range

	switch os, arch := system(); os, arch {
	case "darwin", "amd64":
		fmt.Println("Intel Mac.")
	case "linux", "arm64":
		fmt.Println("Apple Mac")
	default:
		fmt.Printf("Windows %s.\n", os)
	}

Here is are some reference to other languages with different pattern matching style

https://doc.rust-lang.org/rust-by-example/flow_control/match/destructuring/destructure_tuple.html
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/pattern-matching

@findleyr
Copy link
Contributor

findleyr commented Feb 7, 2024

No change in consensus, so declined.

@findleyr findleyr closed this as completed Feb 7, 2024
@findleyr findleyr closed this as not planned Won't fix, can't repro, duplicate, stale Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Projects
Status: Incoming
Development

No branches or pull requests

5 participants