> possibility of using angle brackets Please stop
- call these operator signs “brackets” - pretending they are good in a role of brackets — they are not - spreading this nonsense from C syntax family of languages to saner once — yes, you heard it right. C is known for its chaotic development and lack of careful planning. - thinking yet another strange workaround is a good thing среда, 26 августа 2020 г. в 00:38:00 UTC+3, Kaveh Shahbazian: > I am excited about sum-types as much as generics themselves. Also, it's > nice that any is a keyword restricted to be used inside the type parameter > declaration as a type constraint. > > Very nice! > > --- > > P.S. > Of-course now the proposal seems to go with brackets. Nevertheless, I > wrote this comment > <https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8/m/sMWV1_zSBAAJ> on > the possibility of using angle brackets for the type parameter declaration. > Maybe that way there are more symbols in the language. But they will be > less overloaded with (completely) different semantics - assuming it's a > practical approach. > > On Tuesday, August 25, 2020 at 12:35:33 AM UTC+2 Ian Lance Taylor wrote: > >> On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor <ia...@golang.org> >> wrote: >> > >> > Our intent here is that "any" will be available for all code. Yes, we >> > wouldn't do it if it weren't for its use as a type constraint. But if >> > we are going to do it for type constraints, there seems to be little >> > benefit to restricting it to only work as a type constraint. >> > >> > This is not, of course, a new idea, even in the absence of generics. >> > For example, https://golang.org/issue/33232. (My comment there was >> > that we would use interface{} less if we had generics, but of course >> > when we require type constraints then we actually wind up using it >> > somewhat more.) >> >> I've seen objections that a language change for generics should not >> implicitly pull in a change to non-generic code. That seems fair. It >> may be the right thing to do, but it should be justified separately. >> So we're going to start with "any" only being accepted as a type >> constraint, and we can discuss making the name available for all uses >> separately, probably on issue 33232. Clearly adding "any" as a name >> accepted in type constraints is a step toward defining "any" for all >> code, but doing so isn't a requirement for generics. >> >> Ian >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/41f63ef1-ac34-4d43-88fc-4ce75bcc262dn%40googlegroups.com.
