Generic impl selfs don't really work

[sezna]

title

[sezna]

script;

struct DoubleIdentity<T, F> {
  first: T,
  second: F
}

fn double_identity<T, F>(x: T, y: F) -> DoubleIdentity<T, F> {
  DoubleIdentity {
    first: x,
    second: y
  }
}

fn main() -> bool {
  let double_a = double_identity(true, true);
  let double_b = double_identity(10u32, 43u64);

  // for testing annotations
  let double_a: DoubleIdentity<bool, bool> = double_identity(true, true);
  let double_b: DoubleIdentity<u32, u64> = double_identity(10u32, 43u64);

  double_a.first
}

impl DoubleIdentity<T, F> {
  fn test(a: T) {  }
}

[mohammadfawaz]

An even simpler example seems to have the same problem:

script;

struct DoubleIdentity<T> {
  first: T,
}

impl DoubleIdentity<T> {
  fn test(a: T) {  }
}

fn main() {
}

[emilyaherbert]

Are we wanting this syntax:

impl DoubleIdentity<T, F> {
  fn test(a: T) {  }
}

or this syntax (what Rust does):

impl<T, F> DoubleIdentity<T, F> {
  fn test(a: T) {  }
}

CC @adlerjohn @sezna

[sezna]

We discussed this briefly and I think the simpler syntax is sufficient for us, although I think we should discuss it.

[emilyaherbert]

Personally I feel that this syntax:

impl<T, F> DoubleIdentity<T, F> {
  fn test(a: T) {  }
}

would be a preferable developer experience on Sway. Users will either 1) recognize the syntax coming over from Rust, or will 2) not realize and just acknowledge it as slightly cumbersome at worst. What I want to avoid is a situation in which a Rust person is using Sway and the language constructs for Sway generics diverts their expectations. I feel that if the implementation and use-case for Sway generics is the same as for Rust generics, then the syntax should be the same.

[otrho]

I was wondering why there is this redundancy. From the book:

Note that we have to declare T just after impl so we can use it to specify that we’re implementing methods on the type Point. By declaring T as a generic type after impl, Rust can identify that the type in the angle brackets in Point is a generic type rather than a concrete type. Because this is declaring the generic again, we could have chosen a different name for the generic parameter than the generic parameter declared in the struct definition, but using the same name is conventional. Methods written within an impl that declares the generic type will be defined on any instance of the type, no matter what concrete type ends up substituting for the generic type.

So it's to ensure that T is a generic type in the context of T being a type parameter for the struct.

[otrho]

Is this a similar issue?

script;

struct Wrapper<T> {
    value: T,
}

impl Wrapper<T> {
    fn foo(self) {
    }
}

fn main() {
    let f: Wrapper<bool> = Wrapper { value: true };
    f.foo()
}

   |
29 |
30 |     let f: Wrapper<bool> = Wrapper { value: true };
31 |     f.foo()
   |       ^^^ No method named "foo" found for type "struct Wrapper<bool>".
32 | }
   |

There's no error if you pass f to a function and try calling foo() there.

[sezna]

Yes, monomorphizing on structs and enums was not finished. It was only fully implemented for functions. I'm wrapping that up on my branch right now: #625