On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote:
>
> I don't understand what you are trying to say. You assert that there
> wouldn't be a type-error, but you don't actually justify that.
>
There are 2 examples, both are (to me) intuitive suggestions and not the
result of a phd thesis worth of research :) continued below.
It seems pretty obvious to me, that if you instantiate my MultiReader
> example to, say, *strings.Reader, it would fail to compile. Because
> *multiReader is not a *strings.Reader (and you'd have to replace R with
> *strings.Reader *everywhere* in the signature, that is the exact reason
> we want generics to begin with).
>
That's why I didn't use R for another, distinct Reader. For the signature
of your MultiReader example I changed the return type from "R" (the type
argument) to "Reader" (the name of the contract). In a hand-wavy formal
way, the return type would serve as a new type argument to Reader,
independent of R. Put in an intuitive (to me) way: Since MultiReader
returns something which presumably conforms to the contract Reader, why not
just say that instead of the type argument R?
> The example you give for "unifying this" isn't actually syntactically
> correct, AFAICT. At least I can't find anything in the design that would
> allow using the identifier of the contract in its arguments - and it's
> unclear to me what that would mean.
>
Apologies, I'm responding to the proposal, just giving my 2 cents. I am
not asserting that the examples I give are syntactically correct according
to the proposal. I am suggesting that the concepts of "contract" and
"interface", can (probably) be defined for Go
in a unified way. I am not supposing the definitions in the proposal of
"interface" and "contract" in suggesting this; to the contrary I am
suggesting these concepts are what Go would define them to be and hence are
flexible and not yet fixed. I do not think saying interfaces and contracts
are different because the proposal or other background such as Haskell or
type theory treat them differently is a convincing counterargument to my
suggestion of exploring the unification of contract and interface.
>
> To provide another way to clarify that interfaces and contracts are
> different:
>
This again assumes a priori interfaces and contracts are different. I am
trying to suggest to drop this assumption and see what happens. To me, it
seems, so far, good things would happen.
> * How would you build fmt.Println using contracts?
>
* One of the main motivators behind adding generics is the lack of
> type-safety for containers (say, container/list). While all methods mention
> the same type, interface{}, it is not checked for consistency between
> invocations. This is a bug for type-safe containers, but it's a feature for
> fmt.Println.
>
So perhaps containers could use a contract which does not instantiate each
type argument distinctly, forcing uniformity of types and
more or less like in the proposal. And perhaps situations desiring
heterogenous types, such as fmt,*f(), could use a different kind of
contract which instantiates each type argument independently at the call
site. To distinguish them, some syntax could be proposed such as
contract Reader(r Reader.(*)) { ... }
vs
contract Reader(r Reader) {...}
I am far from the genius who is capable of thinking this idea through and
making it as solid as the proposal overnight. Just expressing the opinion
that unifying the concepts of contract and interface seems to me like a
good idea to explore, and that a priori assuming they are different doesn't
help advance exploring it.
Scott
--
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.
