proposal: Go 2: type and expression super parameters

[zigo101]

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.

[zigo101]

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
}

[zigo101]

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.

[zigo101]

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.

[zigo101]

I decide to close this proposal for more thinking.