• Corngood@lemmy.ml
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    1 year ago

    I’m sure a lot of work went into this, but it seems crazy that we need another way to initialise collections, and another way to make fixed sized arrays.

    I just want less boilerplate.

        • Lucky@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          This is for custom collections, right? And you don’t even have to use it, you can keep using existing ctors for your custom collections

          Worse case scenario you keep doing what we’ve always had to do. But for the 99% of use cases we get a much more streamlined initializer, with extensions to use our own.

          I don’t see how that’s a bad thing

        • TehPers@beehaw.org
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          they actually have to reference the function by string name.

          This is true of a lot of the opt-in language features though, isn’t it? For example, you can just make an .Add method on any IEnumerable type and get collection initializer syntax supported for it, even as an extension method. The same works for Dispose on ref structs I believe, and I remember there being a few other places where this was true (GetAwaiter I think?).

    • eluvatar@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I think for arrays it’s not really a benefit. But for other types it’s superior, compared to the current syntax which just calls add on the list object, which is very inefficient compared to building the whole thing at once which is what this new syntax does.