On Sunday, 9 September 2018 11:49:12 UTC+2, alan...@gmail.com wrote:
>
> [ ... ]
>
> I'm not even sure that it would help all that much with the Go 2 generics
> design as there are some aspects even with the use of operators for the
> built-ins which are difficult or tedious to express in any generic
> constraint system.
>
But that's the crux of the matter, of course: the cart here is "generics"
and the horse is "numeric operators". It is hard to separate overloading
from polymorphism, assuming a restricted version of polymorphism, where the
type-free signature is the same, only certain aspects of the argument types
are allowed to vary, usually in some sort of synchrony, where applicable.
The fact is that the Go developers chose to disallow user-defined
restricted polymorphism: defined "intrinsic" use in instances where it
would just be too painful not to allow it ("+" for string concatenation,
for example, which has no unary equivalent, to my knowledge; also len(),
but not min(), that type of thing) and the exceptions so made now want to
burst out of that box for good or for bad.
One way or another, compromises will be needed to add some polymorphism to
the language, the question is whether we adopt an early proposal and, in my
opinion, whether adopting such a proposal becomes a commitment that may be
regretted later, if or when somebody comes up with a brilliant and elegant
suggestion. Personally, I would prefer to wait, but I'm sure I'm in the
majority that accepts the need to show potential adopters that Go is not
"closed" to conventional ideas (that's called "politics", in my book).
I don't think I will adopt an early proposal, I think we still don't quite
comprehend the possible consequences. But then I refuse to use ++ in my
code (I use += 1, instead), so my views may be too extreme. I do
want (a) to contribute to the design of an early proposal, in the hope of
speeding the arrival of the real thing and (b) to encourage any such design
so we can better judge its import by deploying it in the wild and watching
its effect. Nothing should block this process, no matter how many
deviations might need to be introduced.
Lucio.
PS: I'm beginning to think, though, that selecting types by some unique
operator that the one has and the other doesn't was not the original
intention of (Ian's?) proposal, as Ian himself is at pain to suggest,
perhaps only indirectly. But to a large extent, that is what the proposal
has at its essence and that may be an absolutely terrible idea. Go
interfaces are so defined, indeed, but whereas I can't easily identify it
or describe it, I know there is an essential difference and therein I think
we need to seek the answer. The more I think about it, the more I believe
Ian needs to get his exact vision across: right now, we all seem to
concentrate on what we don't want out of the proposal, thus overlooking the
merits that perhaps Ian alone sees clearly enough.
--
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.
For more options, visit https://groups.google.com/d/optout.
