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: type and expression super parameters #36497

Closed
go101 opened this issue Jan 10, 2020 · 4 comments
Closed

proposal: Go 2: type and expression super parameters #36497

go101 opened this issue Jan 10, 2020 · 4 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@go101
Copy link

go101 commented Jan 10, 2020

Introduction of the proposal

This is not a generic proposal (at least not a generic proposal mainly), though it may solve some problems caused by lack of generics.

An expr super parameter means a lazy-evaluated value. For example, in the following function, b and c will only be evaluated if a is evaluated to true.

func Log(a bool, b string:expr, c ...interface{}:expr) {
	if a {
		fmt.Printf(b, c...)
	}
}

An example using type super parameters:

func make(T Map|Slice|Channel:type, sizes ...int) T {
	switch T.kind {
	case Map:
		return makeMap(T)
	case Slice:
		return makeSlice(T)
	case Channel:
		return makeChan(T)
	}

	panic("invalid kind")
}

func new(T Any:type) *T {
	var t T
	return &t
}

func Add(T String|Numeric:type, a, b T) T {
	return a+b
}

var x = Add(int, 1, 2)
var y = Add(String, "Go", "lang")
var z = Add(float32, 1.23, 7.89)

A type super parameter must be an instance of a kind. The Map, Slice, Channel, String, Numeric and Any used in the above example are some pre-declared kind identifiers. We can also declare custom kinds:

kind MyKind Array|Slice
kind Unsigned Uint8|Uint16|Uint32|Uint64|Uintptr

kind is a new keyword. (In fact, there are not many variations of custom kinds. So this keyword is not very essential.)

In the parameter list, type super parameters must be declared in front of other parameters.

We can view the current general parameter declaration form v T as a simplified form of v T:var.

The syntax is not the core of this proposal. Any improvement ideas are welcome.

Benefits of this proposal

type super parameters are mainly to write some simple custom generic functions.

expr super parameters are mainly to use some functions in a clean but still performant way. For example, when using the glog package, the clean way

glog.V(2).Info(a + b + c + d)

is less efficient than the verbose way if the print doesn't happen finally

if glog.V(2) { glog.Info(a + b + c + d) }

where a + b + c + d is a string concatenation expression.

The current declaration of the Info method:

type Verbose bool

func (v Verbose) Info(args ...interface{}) {
	if v {
		logging.print(infoLog, args...)
	}
}

By using expr super parameters, we can declare it as

func (v Verbose) Info(args ...interface{}:expr) {
	if v {
		logging.print(infoLog, args...)
	}
}

then the above clean way will be as efficient as the verbose way for any cases.

@gopherbot gopherbot added this to the Proposal milestone Jan 10, 2020
@go101
Copy link
Author

go101 commented Jan 10, 2020

Please note that, the "lazy-evaluated" mentioned above means the operations in the said expressions are lazy evaluated, not mean the elementary values in the AST trees of the expressions.

For example, the following program prints 7 (1 + 2*3) instead of 79 (7 + 8*9).

package main

func foo(v int:expr, c <-chan int) int {
	<-c
	return v
}

func bar(x, y int) int {
	return x * y
}

func main() {
    var a, b, c = 1, 2, 3
    var d = make(chain struct{})
    go func() {
    	a, b, c = 7, 8, 9
    	close(d)
    }()
    println(foo(a + bar(b, c), d)) // 7
}

@go101
Copy link
Author

go101 commented Jan 10, 2020

Maybe, to keep the lazy evaluated results the same as if they are not lazy evaluated

  • function calls will never be lazy evaluated.
  • pointer dereferences, selectors, index expressions will never be lazy evaluated.

@go101
Copy link
Author

go101 commented Jan 10, 2020

t looks the troubles brought by expr parameters are more than their benefits.

Now, string concatenation is the only situation I am aware of which needs to be lazy evaluated (or is worth being and not impossible to be implemented). Could compiler optimizations help here? If the answer is yes, I will split this proposal into two.

@ianlancetaylor ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Jan 10, 2020
@ianlancetaylor ianlancetaylor changed the title proposal: type and expression super parameters proposal: Go 2: type and expression super parameters Jan 10, 2020
@go101
Copy link
Author

go101 commented Jan 21, 2020

I decide to close this proposal for more thinking.

@go101 go101 closed this as completed Jan 21, 2020
@golang golang locked and limited conversation to collaborators Jan 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

3 participants