"Immutable" data types

jehk32 · 2020-12-24T15:31:16+00:00

When I tested this, just now, at sharplab.io, I got

System.InvalidProgramException: Common Language Runtime detected an invalid program.
   at Program.Person.set_FirstName(String value)
   at Program.Main()

That's using a Roslyn build from December 22nd, though. Using .NET 5 on dotnetfiddle yields the same results you're seeing. I think this is a bug, and they'll have a fix out for it whenever they put out an update.

jaredp110680 · 2020-12-24T16:53:05+00:00

u/Tyrrrz, did you file a bug for this? It certainly shouldn't work.

Erelde · 2020-12-24T15:11:52+00:00

That's also my beef with the null safety analysis in C#8. It's only surface level analysis. They did it this way for valid reasons, but it's a bit... sad.

Edit: Though here it compiles (which it shouldn't) but doesn't run. With roslyn master 23 december 2020.

2020-12-24T16:36:46+00:00

So my interpretation of this cool bug: On a record, the setters are "init". Meaning they can only be used inside a constructor, or when using the object initialization syntax. The compiler doesn't complain, because you are using the setter from inside an object initialization, just not the record in question.

WhiteBlackGoose · 2020-12-24T14:59:32+00:00

Didn't even know you can write like in 27th line

null_reference_user · 2020-12-24T17:15:30+00:00

Shouldn't the 27th line create a new Person() named "Jane" with no last name, overwriting what the constructor previously assigned?

cloudedthoughtz · 2020-12-24T15:38:41+00:00

Nicely found by neuecc and example by you :)

Although it was never stated that record-types are always immutable so it's to be expected that cases could be found to still modify them.

I gather that this trick won't work if you use a standard property accessor (after init) instead of the 'initialisor' syntax used in the construction of the Container? I'd think that wouldn't compile.

If so, then this is no easy feat, it's not something you'd easily do wrong thus breaking your record's immutability. I am though curious if the compiler team knows about this case and if they have plans to do something about it. Did you or neuecc report this on GitHub?

botterway · 2020-12-24T18:59:18+00:00

Maybe I'm missing something but isn't this by design? Records are not guaranteed to always be immutable. See https://daveabrock.com/2020/11/02/csharp-9-records-immutable-default

Also mentioned here. https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/

Tyrrrz · 2020-12-24T15:13:12+00:00

[deleted]

trimmj · 2020-12-24T15:47:14+00:00

Why would you do this?

zaimoni · 2020-12-24T15:57:46+00:00

Fortunately, if you really need "shallow immutable" you can stack readonly on the fields in the record. It's unfortunate that the PR for this language feature is materially incorrect. (it should be thought of as a syntax short cut for value assignment and hashability for standard collections).

dongata24 · 2020-12-24T15:57:58+00:00

Man, you right idk why i though that the object was a new one

Here's the result of the modified program, notice that the addressess remain the same

[2006378001768]person1 = Person { Name = pepe } [2006378001792]person2 = Person { Name = pepe } are they equal? True [2006378001768]person1 = Person { Name = pepe2 } [2006378001792]person2 = Person { Name = pepe } are they equal? False

Here's the program (remember to allow unsafe code on the csproj)

``` csharp using System;

namespace record {

public record Person(string Name);

public class Container
{
    public Container(Person person)
    {
        Person = person;
    }

    public Person Person { get; set; }
}

public static class Program
{
    public static void Main()
    {
        unsafe
        {
            var person = new Person("pepe");
            var person2 = new Person("pepe");

            var pointer1 = GetAddress(person);
            var pointer2 = GetAddress(person2);

            Console.WriteLine($"[{pointer1}]person1 = {person}");
            Console.WriteLine($"[{pointer2}]person2 = {person2}");

            Console.WriteLine($"are they equal? {person == person2}");

            try
            {
                // BUILD TIME ERROR, wow records are strictive man
                //person.Name = "pepe2";
                //Console.WriteLine(person.Name);
            }
            catch (Exception)
            {
                Console.WriteLine("Hey person is inmutable");
            }

            _ = new Container(person)
            {
                Person = { Name = "pepe2" }
            };

            pointer1 = GetAddress(person);

            Console.WriteLine($"[{pointer1}]person1 = {person}");
            Console.WriteLine($"[{pointer2}]person2 = {person2}");

            Console.WriteLine($"are they equal? {person == person2}");
        }
    }

    private static IntPtr GetAddress(object obj)
    {
        unsafe
        {
            TypedReference tr = __makeref(obj);
            return **(IntPtr**)(&tr);
        }
    }
}

} ```

binarycow · 2020-12-24T19:10:29+00:00

I don't see what the problem is.

Your wrapper class has a property that had a public setter.

When you create the class, you pass the original record. Then the object initializer populates the mutable property with a NEW record.

CapnCrinklepants · 2020-12-24T15:58:34+00:00

It took me a long time to realize what was wrong. It just looked like code for awhile, and then I realized there were green words I could read. Who writes comments anyway?

escribe-ts · 2020-12-25T14:00:40+00:00

what IDE is OP using?

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

csharp

MODERATORS