On Friday, 7 September 2018 20:47:42 UTC+2, Ian Lance Taylor wrote:
>
>
> I think your contracts do require signedness and unsignedness. When
> you ask whether `i << 1` should permit shifting by values other than
> 1, you are going back to the question of what generic function bodies
> are permitted by a given contract. Constants in general are
> definitely one of the more confusing aspects that have to be sorted
> out.
>
> With all possible qualification for my lack of Go prowess, wouldn't
i << int()
suffice to define the scope of the shift value, or i << uint() or, perhaps
unnecessarily cleverly,
i << int(const)
if we do not want to allow variable.
What my uneducated eye sees at the core of the proposed contracts is a new,
extended approach to defining *types*, that assigns categories to them
(classes, of course) based - as interfaces are, for user-defined types -
on methods we call "operators" and operations on such extended "categories".
I think Stroustrup intuitively saw the relationship between operators and
methods, whereas Go counter-intuitively insists that operators somehow
belong to a different functional scope and need to be treated with kid
gloves. If, as Rob Pike did with Ivy, we abandon operators as special,
familiar characters and allow their now "identifiers" to be redefined
(consider the "time" package as an existing example), much of the
complexity of "generics" goes away. Maybe not all of it, but a lot,
definitely.
Please keep in mind I am no expert, I'm a rank amateur in this field and
have already given a lot of uneducated thought to this. For some reason, I
always seem to come back to the need for *types* to be more flexible, for
the predefined "methods" we call "operators" to be categorised, the way
interfaces categorise methods for user-defined types.
In short, banning operator overloading I see as a major obstacle to the
introduction of generic functions and methods and in my naivete, I envisage
equivalent identifier-based methods being used to overcome that.
I guess I ought to expect a fair bit of well-deserved flack for proposing
this...
Lucio.
PS: Maybe I should add a thought to clarify what I'm imagining. Am I
mistaken in my belief that user-defined methods and functions are much less
likely to appear within contracts than operators on intrinsic types? And
that the "generic" nature of operators on intrinsic types lies at the core
of the problem contracts are trying to solve? To some degree, restricting
the use of such generic operators (and Stroustrup also foresaw that
indexing is one such operator, despite its use of two, separate characters,
give him some credit) is the final purpose, much more so than the
"extension" of functions to some concept of "compatibility" between
functions.
If I'm mistaken, I would dearly like a convincing clarification of what I
am seeing with jaundiced eyes.
--
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.
