Spread operator like in es6

[damian2]

class Foo 
{
   string MyStringProp {get;set;}
   int MyIntProp {get;set;}
}

class Bar 
{
   string MyStringProp {get;set;}
   int MyIntProp {get;set;}
   int MyOtherIntProp {get;set;}
}

var foo = new Foo
{
    MyStringProp = "test1",
    MyIntProp = 5
};

before:

var bar = new Bar
{
    MyStringProp = foo.MyStringProp,
    MyIntProp = foo.MyIntProp,
    MyOtherIntProp = 4
};

after:

var bar = new Bar
{
    ...foo,
    MyOtherIntProp = 4
};

[ronnygunawan]

You'll be able to do this with the proposed records:

var bar = bar with { MyOtherIntProp = 4 };

but as @HaloFour pointed out, you can't do this though:

var bar = foo with { MyOtherIntProp = 4 };

[HaloFour]

I don't think "withers" covers anonymous classes or composing instances of new types from instances of other types.

[bbarry]

I don't like how this leaves the order which the properties are evaluated up to the version of the compiler.

Supposing you have this code:

class Foo 
{
  string _s;
  int _i;
  public string S 
  {
    get
    {
      Console.WriteLine("Foo.S_get");
      return _s;
    }
    set 
    {
      Console.WriteLine("Foo.S_set");
      _s = value;
    }
  }
  public int I
  {
    get
    {
      Console.WriteLine("Foo.I_get");
      return _i;
    }
    set 
    {
      Console.WriteLine("Foo.I_set");
      _i = value;
    }
  }
}

class Bar 
{
  int _i;
  string _s;
  public int I
  {
    get
    {
      Console.WriteLine("Bar.I_get");
      return _i;
    }
    set 
    {
      Console.WriteLine("Bar.I_set");
      _i = value;
    }
  }
  public string S 
  {
    get
    {
      Console.WriteLine("Bar.S_get");
      return _s;
    }
    set 
    {
      Console.WriteLine("Bar.S_set");
      _s = value;
    }
  }
  public int Baz { get; set; }
}

Given this code, what order do the console writes happen?

var bar = new Bar
{
  ...foo,
  Baz= 4
};

[IlBaffo]

I'd treat this case as using Type.GetMembers to iterate the members:

The GetMembers method does not return members in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which members are returned, because that order varies.

So, if your code depends on the order you should use some other tool.
Maybe an explicit order could be enforced with attributes? Like [JsonProperty(Order = 1)]

The killer application for me is mapping POCO objects for OData usage in selects and the order does not matter to me.

[spydacarnage]

The pedantic answer is that none of them run because the code won't compile (you're setting and returning _s in your int I property. However, assuming that's not what you meant, I would assume the compiler would be written to use _an_ order, but that would probably be alphabetical.

…

On Thu, 10 Oct 2019, 17:11 Bill Barry, ***@***.***> wrote: I don't like how this leaves the order which the properties are evaluated up to the version of the compiler. Supposing you have this code: class Foo { string _s; int _i; public string S { get { Console.WriteLine("Foo.S_get"); return _s; } set { Console.WriteLine("Foo.S_set"); _s = value; } } public int I { get { Console.WriteLine("Foo.I_get"); return _s; } set { Console.WriteLine("Foo.I_set"); _s = value; } } } class Bar { int _i; string _s; public int I { get { Console.WriteLine("Bar.I_get"); return _s; } set { Console.WriteLine("Bar.I_set"); _s = value; } } public string S { get { Console.WriteLine("Bar.S_get"); return _s; } set { Console.WriteLine("Bar.S_set"); _s = value; } } public int Baz { get; set; } } Given this code, what order do the console writes happen? var bar = new Bar { ...foo, Baz= 4 }; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/2879?email_source=notifications&email_token=ADIEDQKZEDAE7Q3PISDS633QN5H3BA5CNFSM4I7NU7DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA4447A#issuecomment-540659324>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADIEDQKPU5CDWCVGGSHMTX3QN5H3BANCNFSM4I7NU7DA> .

[theunrepentantgeek]

I don't know what effect this operator has on JavaScript developers, but (on first inspection) it would seem to introduce a very fragile form of tight coupling between types.

var bar = new Bar
{
    MyStringProp = foo.MyStringProp,
    MyIntProp = foo.MyIntProp,
    MyOtherIntProp = 4
};

With the above code, any renaming of the properties of foo will result in code that still does exactly what is intended - two properties from foo will be copied across to bar. Adding new properties to either type will have no effect.

var bar = new Bar
{
    ...foo,
    MyOtherIntProp = 4
};

On the other hand, the link between foo and bar here is far more tenuous.

Renaming either MyStringProp or MyIntProp from foo would silently result in the value not being copied across. No warning, no error, just missing data.

Even worse, an innocent enhancement of foo - a new property on foo that accidentally matched an existing property on bar would result in unexpected behaviour. Either the value would be silently copied across (if they're type compatible) or you'd get a compiler error (if they weren't).

To me, this behaviour is inconsistent with the strongly typed nature of the C# language.

[chriskuech]

This "tight coupling" occurs in any standard multitier web service architecture explicitly for the purpose of decoupling the layers. Rather than every layer using the same type, the type is (basically) defined multiple times with mappings between the types. To circumvent this, AutoMapper is a very popular alternative, but that pushes the operation to runtime, even though this is a statically verifiable problem and should therefore be solved in the compiler. Please realize that people who don't want such coupling don't need to use the feature, but you are certainly not preventing such coupling by not supporting the feature--only maximizing the number of runtime issues caused by it.

[jzabroski]

@chriskuech You can use a Roslyn tool to auto-complete the mapping logic so that you have statically verifiable mappings. Cezary Piatek even did so.

[chriskuech]

Thank you this seems like the best solution.

[damian2]

You would have the same problem using AutoMapper, but I think most of the programmers using it.

[ronnygunawan]

Renaming either MyStringProp or MyIntProp from foo would silently result in the value not being copied across. No warning, no error, just missing data.

I think a proper implementation would not allow spread receiver to not have all spread object's properties.

@damian2 you can also use reflection to achieve that:

public static class SpreadExtension
{
    public static TTarget Spread<TSource, TTarget>(this TTarget target, TSource source)
    {
        foreach (PropertyInfo sourceProp in typeof(TSource).GetProperties())
        {
            PropertyInfo targetProp = typeof(TTarget).GetProperty(sourceProp.Name);
            targetProp.SetValue(target, sourceProp.GetValue(source));
        }
        return target;
    }
}

Usage:

var bar = new Bar {
    MyOtherIntProp = 4
}.Spread(foo);

[Vlad-Stryapko]

You would have the same problem using AutoMapper, but I think most of the programmers using it.

I've worked with dozens of projects with AutoMapper and I can assure you debugging and reasoning about the code with implicit effects is not a pleasurable experience.

IMO it's better to write a bit more but be able to easily see which property is used and which is not. I'm strongly against implicit assignments and mappings just because one has to spend one more minute to explicitly write them down.

[chriskuech]

AutoMapper is the 8th most popular package on NuGet right now. Regardless of whether one should use it or not, C# developers are overwhelmingly using it. The only way I think I could convince people to not use it would be if there were a statically verifiable alternative, such as with the spread operator.

[jzabroski]

Wow, GitHub Discussions does NOT work well for converted issues. This whole AutoMapper side conversation got really hard to follow, fast.

That said, AutoMapper does many things, so it's not clear to me why you think mimicking a spread-like operator is why people use AutoMapper.

As an example, here is how KubernetesClient (2.9M downloads and thus a huge portion of recent AutoMapper transitive download count) uses it - to map between a beta API and official API data contract:

AutoMapper config:
https://github.com/kubernetes-client/csharp/blob/16845bae1d8dda30407b3bdb375a9b5800eca12c/src/KubernetesClient/generated/VersionConverter.cs

example co-classes:
https://github.com/kubernetes-client/csharp/blob/fcd8c166daa79278fed5a9306b279fb41783b58d/src/KubernetesClient/generated/Models/Admissionregistrationv1beta1ServiceReference.cs

https://github.com/kubernetes-client/csharp/blob/8ab95b6b920e8a10b4c0122e09d158be2005aa15/src/KubernetesClient/generated/Models/Admissionregistrationv1ServiceReference.cs

And this is LITERALLY how the author of AutoMapper recommends using AutoMapper.

The use case is not the spread operator.

[chriskuech]

Not sure what you mean. In your example, they have two different types with the same properties and they use automapper to map between those two types. That is the majority of what my team currently uses automapper for. That hidden runtime magic could be explicit and compile time with the spread operator:

var betaEntity = new Admissionregistrationv1beta1ServiceReference { ...v1Entity };

var v1Entity = new Admissionregistrationv1ServiceReference { ...betaEntity };

[jzabroski]

@ronnygunawan I think you're missing the motivation for the syntactic sugar.

@damian2 I think the motivation for this operator is poor. The saying goes, "Amateurs imitate, professionals steal."; the true motivation for this operator is best given in the dart language GitHub, introduced in Dart 2.3:

1. The Spread operator (…)
   Consider the following List of Text Widgets:

List<Widget> northAmericanCountries = [
  Text('USA'),
  Text('Canada')
];

List<Widget> asianCountries = [
  Text('India'),
  Text('China')
];

List<Widget> europeanCountries = [
  Text('France'),
  Text('Germany'),
  Text('Italy')
];

If we were to add all of these to a Row Widget, normally, we’d be doing something like this:

The problem with this is that if you wanted to add asianCountries first and then add northAmericanCountries, you’d have to include asianCountries first in the Row like so:

Row(
  children: asianCountries
            ..addAll(northAmericanCountries)
            ..addAll(europeanCountries),
)

This requires you to re-order the addAll methods to your lists, which isn’t exactly convenient or ideal.

Enter, the new Spread operator! With the Spread operator, you can achieve the above result easily:

Row(
     children: [
               ...northAmericanCountries
               ...asianCountries
               ...europeanCountries
               ]
)

And this can be easily re-ordered like so:

Row(
     children: [
               ...asianCountries
               ...northAmericanCountries
               ...europeanCountries
               ]
)

[IlBaffo]

I've worked with dozens of projects with AutoMapper and I can assure you debugging and reasoning about the code with implicit effects is not a pleasurable experience.

IMO it's better to write a bit more but be able to easily see which property is used and which is not. I'm strongly against implicit assignments and mappings just because one has to spend one more minute to explicitly write them down.

I'm with you on that but, in my case, is not about "one minute" because, especially in LOB applications I end up with a lot of EntityFramework Selects which can't be DRYed out because they have to be translated to SQL and there are a lot of properties.
What happens is that I have an Order object with some navigation properties maybe two or three levels deep with 20/30 properties and that tends to grow a lot.

Now imagine that you'd like to add a property with the value from the current "request" and you have to inject it with some AutoMapper's voodoo.

What I dislike the most, apart from writing a lot, is that this has to be done via reflection wasting resources for something that is known at compile time.

But yes, I think that it can be fragile and needs to be well thougth and limited to specific use-cases.

[cordasfilip]

I am not sure why this is not considered but the way TypeScript/Javascript dose it works well for immutability and with operator is just cumbersome.
In TS/JS it also works on arrays and in C# it could be applied to dictionaries and tuples. But I think this could also work on method calls as well as constructors.
so this
`public void Method1(string a, string b)

struct A
{
int a = 5;
int b = 5;
}`

could work like this
var a = new A(); Method1(...a);
dose the same as Method(a:a.a,b:a.b)

[derekantrican]

Correct me if I misunderstand the spread operator or if someone's already mentioned this

I think one useful application of the spread operator in C# could be reducing something like this:

public List<string> InsertList(List<string> secondList)
{
    List<string> myList = new List<string>
    {
        "firstItem",
    };

    myList.AddRange(secondList);

    myList.Add("lastItem");

    return myList;
}

into this:

public List<string> InsertList(List<string> secondList)
{
    return new List<string>
    {
        "firstItem",
        ...secondList,
        "lastItem",
    };
}

Essentially an AddRange that can be put in the object initializer.

[derekantrican]

@ronnygunawan pointed out in a comment below that this can be done currently with an Extension method:

public static class CollectionExtensions
{
    public static void Add<T>(this ICollection<T> collection, IEnumerable<T> items)
    {
        foreach (T item in items)
        {
            collection.Add(item);
        }
    }
}

public List<string> InsertList(List<string> secondList)
{
    return new List<string>
    {
        "firstItem",
        secondList,
        "lastItem",
    };
}

[jnm2]

This ability is now shipped with C# 12! https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/collection-expressions#spread-element

[cordasfilip]

It didn't really still missing for object initializers

[jnm2]

@cordasfilip I was replying to the thread that was about applying the concept to collections.

[spixy]

If spread operator will be implemented, why not with some useful features (inspired by Dart):

return new List<string>
{
    "firstItem",
    if (hasSecondItem) "secondItem",  // only one-liner allowed
    ...thirdList,  // list has type List<T>
    ...?thirdNullableList,  // list has type List<T>?
    for (var i in forthList) $"#{i}",  // only one-liner allowed
    for (var i in forthList) yield $"#{i}",  // alternative syntax?
    "lastItem",
};

[ronnygunawan]

This can be easily implemented as an extension:

public static class CollectionExtensions {
    public static void Add<T>(this ICollection<T> collection, IEnumerable<T> items) {
        foreach (T item in items) {
            collection.Add(item);
        }
    }

    public static void Add(this ICollection<int> collection, Range range) {
        collection.Add(range.AsEnumerable());
    }
}

public static class RangeEnumerableExtensions {
    public static IEnumerable<int> AsEnumerable(this Range range) {
        if (range.Start.IsFromEnd) throw new InvalidOperationException("IsFromEnd is not allowed.");
        if (range.End.IsFromEnd) throw new InvalidOperationException("IsFromEnd is not allowed.");
        for (int i = range.Start.Value; i < range.End.Value; i++) {
            yield return i;
        }
    }
}

Then we can do this with collection initializer:

record Foo {
    public List<int> Items { get; } = new();
}

var items = new[] { 1, 2, 3 };

var foo = new Foo {
    Items = {
        items, // spread array

        4, 5, 6, // add values normally

        from i in items // spread IEnumerable
        let j = 10 - i
        orderby j ascending
        select j,

        10..13 // spread range
    }
};

// foo.Items: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12

[jnm2]

Starting in C# 12, this is now possible (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/collection-expressions#spread-element):

return (List<string>)[
    "firstItem",
    .. hasSecondItem ? new[] { "secondItem" } : [],
    .. thirdList,
    .. thirdNullableList ?? [],
    .. from i in fourthList select $"#{i}",
    "lastItem",
];

[GabrielEcoDev]

spread operator of objects when? :(

[CyrusNajmabadi]

@GabrielEco1 we update proposals when they are accepted into the language.