Hi Burak,
So, how about to change the idea to accept contracts as restrictions to
generic types?
For example:
This is defined on
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
contract stringer(x T) {
var s string = x.String()}
Could be expressed this way:
type stringer generic{
contract String() string
}
Alternatively it could have multiple definitions:
This is defined on
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
contract adjustable(x T) {
var _ T = x.Adjust()
x.Apply()}
Could be expressed this way:
type adjustable generic{
contract ( Adjust() adjustable
Apply() )}
So, changing this way could solve this issue?
Best regard,
Luis Otávio
On Fri, Jun 7, 2019 at 12:17 PM Burak Serdar <bser...@ieee.org> wrote:
> On Fri, Jun 7, 2019 at 7:32 AM Luis Furquim <luisfurq...@gmail.com> wrote:
> >
> >
> >
> > Hello gophers,
> >
> > I have almost no experience on language definitions/proposals and on
> generics.
> > But an idea came to my mind and I wanted to share it.
> > It is an idea, not a proposal, I haven't worked on
> detailing/elaboration, etc.
> > As stated on my gist, I got the text and examples from Faiface gist and
> adapted to my idea.
> > No plagiarism intent, just to quickly have something readable by people.
> > But, if people finds the copy/edit method I used is offensive, just
> point this and I may delete the gist.
>
>
> One problem with this type of generic types is the lack of type
> checking at the time of generic compilation. You can only type check
> the generic functions when they are instantiated and that can cause
> hard to decipher error messages. The contracts idea was promoted to
> eliminate those.
>
> >
> > So, here is the gist:
> > https://gist.github.com/luisfurquim/548c37870f7ed5a57a1f91a696cfc62f
> >
> > Best regards,
> > Luis Otavio
> >
> >
> > Em quinta-feira, 30 de maio de 2019 13:29:03 UTC-3, Michal Strba
> escreveu:
> >>
> >> Hi Gophers! :)
> >>
> >> I've been thinking about generics in Go 2 ever since the original
> contracts proposal and few days ago, ideas finally clicked. One of the main
> things about this proposal is that it deliberately omits the ability to
> restrict the set of types a function can work with. This is a limitation,
> but I hope to convince you that we can still do a vast majority of the
> things we were missing, when we were missing generics.
> >>
> >> I'd love to share my proposal with you and engage in a good faith
> conversation.
> >>
> >> Link to the proposal.
> >>
> >> Here's what the proposal covers:
> >>
> >> 1. Syntax of a new gen keyword.
> >> 2. Generic functions.
> >> 3. Unnamed generic arguments (a.k.a. a way to gve a type to the
> built-in new function).
> >> 4. Semantics of generic values (ability to use them as map keys, ...).
> >> 5. Generic array lengths.
> >> 6. Reflection and interface{}.
> >> 7. Generic types (with two examples: List and Matrix).
> >> 8. Generic methods and their limitations due to reflection.
> >> 9. Generic interfaces.
> >> 10. List of things this proposal can't do.
> >>
> >> Thanks,
> >> faiface
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d284f74d-1e2c-474e-bc0d-a30413d17d98%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
--
Luis Otavio de Colla Furquim
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CACyQ4W6LasZnem6qJqmJfpRFX%2BP_CesMyUfXqTr7%2BMOrshnqzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
