Yes, but you can just specify the concract like :
contract doubleLinkedListNode {
X struct {
*X
*X
}
}
which defines a type X containing at least two pointers to values of type
X. You'd do the same currently for a function type --> func (int, int,
string), which takes two ints in its arguments (along with a string), but
you do not name the parameter. I think one might not forget that we're
talking "type signature" here, and not type definition :)
Le mar. 20 nov. 2018 à 15:26, Burak Serdar <bser...@ieee.org> a écrit :
> On Tue, Nov 20, 2018 at 6:27 AM Michel Levieux <m.levi...@capitaldata.fr>
> wrote:
> >
> > I guess X is the type that is represented by the struct, the meaning
> being : "the type X is a struct that contains a field that is a pointer to
> a value of the same type".
> >
> > EDIT : I think the "next" word, which is here the name of the field, can
> even be omitted. The relevant information here is to know the type X
> contains a field of type *X, whether this field is named "next" or "child"
> or anything else does not break the viability of the expression.
>
> Name of the field cannot be omitted. For a doubly linked list, you'll
> need two of those, prev and next, and if you have a function working
> on a node satisfying that contract, it has to access both of those
> fields.
>
>
>
> >
> >
> > Le mar. 20 nov. 2018 à 12:38, komuW <komu...@gmail.com> a écrit :
> >>>
> >>> A contract can also be written in terms of a struct:
> >>>
> >>> contract linkedListNode {
> >>> X struct {
> >>> next *X
> >>> }
> >>> }
> >>
> >>
> >> In this example taken from the linked document; what is X?
> >>
> >>
> >> On Tuesday, 20 November 2018 05:38:31 UTC+3, Burak Serdar wrote:
> >>>
> >>> Hi,
> >>>
> >>> A while ago I sent an email to this list proposing an alternative way
> >>> to specify contracts using existing types, with a "like" keyword to
> >>> represent contracts on primitives. The idea stirred up some
> >>> discussion, I got some useful feedback, and eventually, it died down.
> >>> The idea stuck with me though, because it wasn't complete when I
> >>> proposed it, it had inconsistencies and unresolved problems. It turned
> >>> into this puzzle that I kept working on on the side, I started writing
> >>> a contracts/generics simulator, which I never finished, but it allowed
> >>> me to figure out a way to solve the problems the original idea had. So
> >>> the latest version of that proposal is now here:
> >>>
> >>> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> >>
> >> --
> >> 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.
> >
> > --
> > 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.
>
--
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.
