<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Dec 23, 2016, at 04:08, Антон Жилин <<a href="mailto:antony.zhilin@gmail.com">antony.zhilin@gmail.com</a>> wrote:</div><blockquote type="cite"><div><br></div><div>On 2) and 3), I feel like @pure and variadic generics/tuples would cover most of the use cases.</div>
</blockquote><br><div>How so? I agree that variadic tuples could replace the third example (quite well, actually), but I don't see how they or @pure (alone or in combination) have the same functionality in general. With default generic parameters, you could effectively have <i>partial</i> sub-typing of non-reference types. You wouldn't be able to add any non-computed properties, but every function and computed property could have a different implementation depending on the value of the generic parameter in question. Of course, we <i>could</i> do this now, but it'd be quite annoying to have to specify, say, 5 configuration every parameter when most of the time they have the same value (and it'd be quite easy to make a mistake in their order without the labels reminding you what goes where).</div><div><br></div><div>Is your claim that, regardless of whether their functionality <i>exactly</i> overlaps, for any given use case for 2&3, there's a semantically (as opposed to syntactically) equivalent way to do it with the existing language plus @pure or variadic generics/tuples? Strictly speaking, I'm not sure I can disprove that. It seems to me, though, that it'd be easier to have an 'Array<T, Length: 3, FixedSize: true>' interoperate with the rest of the stdlib than it would a '(T, T, T)'. (Don't misunderstand me, though, I'm still very much in favor of enhancing tuples... they solve different problems.)</div><div><br></div><div>- Dave Sweeris</div></body></html>