Is "Craftsman's approach" proposal generic enough?

[Wojciech S. Czarnecki]

[ Subject: Was: [go-nuts] I am not in favor of generics.

This is continuation of a thread that went off the rails, now with
more appropriate Subject. Previous thread is at:
https://groups.google.com/d/msg/golang-nuts/3ia8XrUgqOg/LOsTL8ZlGAAJ
]

On Wed, 19 Sep 2018 09:32:39 -0500
Robert Engels <ren...@ix.netcom.com> wrote:

> This is not what I am referring to.
>>> Also, I did read what you wrote. I questioned “what happens when you have
>>> N different generic types in the call signature. The select type
>>> statement has N*N cases. “.

Seem that I misunderstood. N*N (both N) straw man was so huge it blinded me.
I humbly apologize, I should expect.

> I am stating that with N generics types in a method the developer needs to
> write NxN case methods.

That's a false statement.

With N input type holders* in the generic func signature the developer needs
to write _at_least_ N **constraints** in the func's contract - one per each
input typeholder. A `for type switch` case constraints counts as a part of the
contract, ofc.

There is no upper limit to number of constraints but with more than a few
different constraints there will likely be no concrete type that can pass
contract check.

* CGG type holder is NOT a "formal type parameter". CGG does not "instantiate
formal type parameters with type arguments" as in c++/java. Type holders
represent, for the contract checking purpose, "type of the object that call
site is passing to the generic func". Typeholder identifiers are used in
contracts, not in the code. (Spare return-typeholder concretization, that
is to be seen at Go code level).

I.e. typeholder identifiers are NOT used in generic func code (except
return type concretization in `for type switch`). These identifiers are
for contracts. CGG generic code is plain Go code.


relevant CGG proposal excerpts:
==============================================
What is required is written into the contract.
What is not required does not matter hence it
has no place in the contract.

The for type contract consists of required by
the author of the code constraints on ALL of
"in" typeholders. [conjugated]

All constraints in for type contract must be
fulfilled by the substituted type for it to
pass.


==============================================
Seem that it is not enough clear :(
Should the "Terms" paragraph be more descriptive?
What terms I used are most confusing?

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE