Conversation

it does mean that you can now have a total of four sets of parens in a function def: func (type T) (s Foo*) Bar(arg1 Baz, arg2 Baz2) (bool, Quux)

Manish

@ManishEarth

not ... terrible, and I still think it's an overall good choice, but still kinda weird

It makes it clearer that generics are functions applied to types, I like it a lot. Gives Go a leg up on the path to dependent types!

Anthony Ramine

@nokusu

Step 1: get tagged unions.

It should already have them, tagged unions are compatible with the "Go philosophy" in every way I can think of... every language should have them though.

Anthony Ramine

@nokusu

AFAIK the Powers That Be say that tagged unions don't bring much to interface types so they don't want them.

My first instinct is to say "but those aren't the same thing!" but if it's a feature-for-feature trade I'd happily give up interfaces for tagged unions. Can always use records with functions in them instead, they're not even that bad to use.

Brendan Zabarauskas

@brendanzab

I thought the issue was more that they started out with the assumption that everything needed a default value. Anyway, that means it's hard to have a default for tagged unions (which should have given them a hint that defaults for everything is kinda ick, but egh).

2:02 PM · Aug 1, 2019Twitter Web App

It's not hard to have a default for tagged unions anyway, just make people specify one as the default (though why you insist on this I have no earthly idea).

Replying to

and

I'm _guessing_ because they were coming from a C perspective and wanted to ensure everything was zero initialised to start off with because it was safer. And then a whole tower of design decisions were built atop that.

Replying to

and

I think any inhabited tagged union could be valid with memset 0, with reasonable restrictions on representation, under the assumption that 0 was also a valid value for every other type. It wouldn't work for Rust but it could easily work for another language.

Replying to

Where as a better solution is to ensure that things are always assigned a value on construction. That seems to give you much more room to move in the design space, and leads to less code that constructs things in invalid states (this is rampant from what I've seen).