rcoreilly

This proposal changes the syntax for type parameters on functions, to eliminate the extra parens which are widely raised as a major problem with the draft proposal. It retains type parameters for types, and should otherwise be very similar to the draft proposal, just with a simpler syntax.

The key idea is: use generic type names just as we use concrete types now, instead of having separate type parameters. (Generic Types, GT)

GT puts all the type information in one place, instead of distributing it across two locations, greatly reducing cognitive load, and eliminates the extra parens in function calls which are confusing and a constant complaint about the draft proposal.

• Constraints are now interface types, so use these interface types directly as type names.
• For fully generic, unconstrained types, use the keyword type.
• Semantically, there are two categories of interface types: generic

rcoreilly

Dear Apple,

If you're going to force people to use usb-c ports exclusively, they are going to end up with multiple dongles, so please at least put the !$%@$ ports far enough apart so you can actually fit the dongles.

Thank you,

• Randy

rcoreilly

What is the role of Computer Science in a Liberal Arts Undergraduate Education?

This is my perspective, as someone who has relied extensively upon computer science for my entire career (and life!) but who has never majored in CS (only "Cognitive Science") and who has recently joined the CS Department with a 50% affiliation, and is now in a position to potentially have an official opinion about such things (or at least 50% of one).

Disclaimers: I like to write out ideas as a way of exploring them (much like writing programs) and I haven't really thought through the implications of any of this for actual policy, and recognize that some / all of it may be really bad for the CS dept, and also that it clearly reflects my "end user" / "coder" perspective on CS. Also, much of this may be blatantly obvious but anyway it seems like at least it leads to certain conclusions that may be worth considering, in the context of current or future discussions of Data Science, etc.

Three main points:

CS is Universal,

rcoreilly

This proposal is to add generic native types (GNTs) to Go: generic versions of each of the native builtin types (e.g., map = generic map, slice = generic slice, number = generic number, float = generic float, signed = generic signed integer, unsigned = generic unsigned integer, etc).

GNTs support a substantial proportion of generic programming functionality, without adding any new syntax to the language: generic code looks identical to regular Go code, except for the use of these generic type names, and a few extra functions that access the type parameters of container objects such as maps and slices (e.g., elem(x) is the type of the elment in a slice or map; key(m) is the type of the key of a map; field(s, fieldName) is the type of the given named field in a struct; return(f) is the type of return value from function, and type(x) is the type of a generic var, e.g., for use in return signature).

The generic struct is the most challenging case, because of its unlimited number of t

rcoreilly

Go (golang) Proposal: Generic Native Types

This is a proposal for generics in Go based on generic versions of existing native types in the language (Generic Native Types or GNT). Instead of supporting completely flexible contracts that can specify all manner of constraints on types that can be used in generic code, use the existing, well-known type kinds already in Go as a fixed set of contracts with builtin (keyword) names.

Examples:

func Keys(m map) []key(m) {
    s := make([]key(m), len(m))
    idx := 0