Типы действительно ли значения неизменны по определению?

Изменяемость и типы значений - это две разные вещи.

Определение типа как типа значения указывает, что среда выполнения будет копировать значения вместо ссылки на среду выполнения. С другой стороны, изменчивость зависит от реализации, и каждый класс может реализовать ее по своему усмотрению.

Не хочу усложнять рассуждения об этом, учитывая ссылку параметры и бокс. Я также в курсе что p = p.Offset (3, 4); выражает неизменность намного лучше, чем p.Offset (3, 4); делает. Но остается вопрос - не типы значений неизменный по определению?

Что ж, тогда вы действительно не работаете в реальном мире, не так ли? На практике склонность типов значений создавать копии самих себя при перемещении между функциями хорошо сочетается с неизменяемостью, но на самом деле они не являются неизменяемыми, если вы не сделаете их неизменяемыми, поскольку, как вы указали, вы можете использовать ссылки на них просто как и все остальное.

Вы можете писать изменяемые структуры, но лучше всего сделать типы значений неизменяемыми.

Например, DateTime всегда создает новые экземпляры при выполнении любой операции. Point является изменяемым и может быть изменено.

Отвечу на ваш вопрос: Нет, они не являются неизменяемыми по определению, это зависит от случая, должны они быть изменяемыми или нет. Например, если они должны служить ключами словаря, они должны быть неизменными.

не являются типами значений неизменяемыми по определению. ?

Нет, это не так: если вы посмотрите, например, на структуру System.Drawing.Point , у нее есть сеттер, а также геттер в свойстве X .

Однако может быть верно сказать, что все типы значений должны быть определены с помощью неизменяемых API.

Если вы углубитесь в свою логику, то все типы являются неизменяемыми. Когда вы изменяете ссылочный тип, вы можете утверждать, что вы действительно пишете новый объект по тому же адресу, а не изменяете что-либо.

Или вы можете утверждать, что все является изменяемым на любом языке, потому что иногда память, которая имела ранее использовался для одного, будет заменен другим.

Имея достаточно абстракций и игнорируя достаточное количество языковых функций, вы можете прийти к любому выводу, который вам нравится.

И это упускает суть. Согласно спецификации .NET, типы значений изменяемы. Вы можете изменить его.

int i = 0;
Console.WriteLine(i); // will print 0, so here, i is 0
++i;
Console.WriteLine(i); // will print 1, so here, i is 1

но он все тот же i. Переменная i объявляется только один раз. Все, что происходит с ним после этого объявления, является модификацией.

В чем-то вроде функционального языка с неизменяемыми переменными это было бы незаконно. ++ i было бы невозможно. После объявления переменной она имеет фиксированное значение.

В .NET это не так, мне ничто не мешает изменить i после того, как она была объявлена.

Поразмыслив немного над этим, вот еще один пример, который может быть лучше:

struct S {
  public S(int i) { this.i = i == 43 ? 0 : i; }
  private int i;
  public void set(int i) { 
    Console.WriteLine("Hello World");
    this.i = i;
  }
}

void Foo {
  var s = new S(42); // Create an instance of S, internally storing the value 42
  s.set(43); // What happens here?
}

В последней строке, согласно вашей логике, мы могли бы сказать, что мы фактически создаем новый объект и перезаписываем старый с этим значением. Но это невозможно! Чтобы создать новый объект, компилятор должен установить для переменной i значение 42. Но это закрыто! Он доступен только через определяемый пользователем конструктор, который явно запрещает значение 43 (вместо этого устанавливая его на 0), а затем через наш метод set , который имеет неприятный побочный эффект. У компилятора нет способа просто создать новый объект с теми значениями, которые ему нравятся. Единственный способ установить si на 43 - это изменить текущий объект, вызвав set () . Компилятор не может просто сделать это, потому что он изменит поведение программы (она будет выводить на консоль)

Таким образом, для того, чтобы все структуры были неизменными, компилятор должен был обмануть и нарушить правила языка , И конечно, если мы Если хочешь нарушить правила, мы можем доказать что угодно. Я мог бы доказать, что все целые числа тоже равны или что определение нового класса приведет к возгоранию вашего компьютера. Пока мы остаемся в рамках правил языка, структуры изменчивы.

I think the confusion is that if you have a reference type that should act like a value type it's a good idea to make it immutable. One of the key differences between value types and reference types is that a change made through one name on a ref type can show up in the other name. This doesn't happen with value types:

public class foo
{
    public int x;
}

public struct bar
{
    public int x;
}


public class MyClass
{
    public static void Main()
    {
        foo a = new foo();
        bar b = new bar();

        a.x = 1;
        b.x = 1;

        foo a2 = a;
        bar b2 = b;

        a.x = 2;
        b.x = 2;

        Console.WriteLine( "a2.x == {0}", a2.x);
        Console.WriteLine( "b2.x == {0}", b2.x);
    }
}

Produces:

a2.x == 2
b2.x == 1

Now, if you have a type that you'd like to have value semantics, but don't want to actually make it a value type - maybe because the storage it requires is too much or whatever, you should consider that immutability is part of the design. With an immutable ref type, any change made to an existing reference produces a new object instead of change the existing one, so you get the value type's behavior that whatever value you're holding cannot be changed through some other name.

Of course the System.String class is a prime example of such behavior.

Нет, это не так. Пример:

Point p = new Point (3,4);
Point p2 = p;
p.moveTo (5,7);

В этом примере moveTo () является операцией на месте . Это меняет структуру, которая скрывается за ссылкой p . Вы можете увидеть это, посмотрев на p2 : его положение также изменится. С неизменяемыми структурами moveTo () должен будет возвращать новую структуру:

p = p.moveTo (5,7);

Теперь Point неизменяем, и когда вы создаете ссылку на нее в любом месте вашего кода, вы выигрываете Никаких сюрпризов. Давайте посмотрим на i :

int i = 5;
int j = i;
i = 1;

Это другое. i не является неизменным, 5 является. И второе присваивание не копирует ссылку на структуру, содержащую i , а копирует содержимое i . Итак, за кулисами, происходит нечто совершенно иное: вы получаете полную копию переменной, а не только копию адреса в памяти (ссылка).

Эквивалентом объектов может быть конструктор копии:

Point p = new Point (3,4);
Point p2 = new Point (p);

Здесь внутренняя структура p копируется в новый объект / структуру, а p2 будет содержать ссылку на него. Но это довольно дорогостоящая операция (в отличие от целочисленного присваивания выше), поэтому большинство языков программирования делают различие.

По мере того, как компьютеры становятся более мощными и получают больше памяти, это различие исчезнет, ​​потому что оно вызывает огромное количество ошибок и проблем. В следующем поколении будут только неизменяемые объекты, любая операция будет защищена транзакцией, и даже int будет полноценным объектом. Так же, как и сборка мусора, это будет большим шагом вперед в стабильности программы, вызовет много проблем в первые несколько лет, но позволит писать надежное программное обеспечение. Сегодня компьютеры для этого недостаточно быстры.

Нет, типы значений не неизменяемы по определению

Во-первых, мне лучше было бы задать вопрос «Типы значений ведут себя как неизменяемые типы?» вместо того, чтобы спрашивать, являются ли они неизменяемыми - я полагаю, это вызвало большую путаницу.

struct MutableStruct
{
    private int state;

    public MutableStruct(int state) { this.state = state; }

    public void ChangeState() { this.state++; }
}

struct ImmutableStruct
{
    private readonly int state;

    public MutableStruct(int state) { this.state = state; }

    public ImmutableStruct ChangeState()
    {
        return new ImmutableStruct(this.state + 1);
    }
}

[Продолжение следует ...]

Объекты / структуры неизменяемы, когда они передаются в функцию таким образом, как данные не могут быть измененным, и возвращенная структура является структурой новая . Классический пример:

String s = "abc";

s.toLower ();

, если функция toLower записана так, что возвращается новая строка, заменяющая "s" , это неизменный,

В прошлом году я написал в блоге сообщение о проблемах, с которыми вы можете столкнуться, не создавая структуры неизменяемый.

Полную версию сообщения можно прочитать здесь

Это пример того, как что-то может пойти не так:

//Struct declaration:

struct MyStruct
{
  public int Value = 0;

  public void Update(int i) { Value = i; }
}

Пример кода:

MyStruct[] list = new MyStruct[5];

for (int i=0;i<5;i++)
  Console.Write(list[i].Value + " ");
Console.WriteLine();

for (int i=0;i<5;i++)
  list[i].Update(i+1);

for (int i=0;i<5;i++)
  Console.Write(list[i].Value + " ");
Console.WriteLine();

Вывод этого кода:

0 0 0 0 0
1 2 3 4 5

Теперь давайте сделаем то же самое, но заменить массив на общий List <> :

List<MyStruct> list = new List<MyStruct>(new MyStruct[5]); 

for (int i=0;i<5;i++)
  Console.Write(list[i].Value + " ");
Console.WriteLine();

for (int i=0;i<5;i++)
  list[i].Update(i+1);

for (int i=0;i<5;i++)
  Console.Write(list[i].Value + " ");
Console.WriteLine();

Результат:

0 0 0 0 0
0 0 0 0 0

Объяснение очень простое. Нет, это не упаковка / распаковка ...

При доступе к элементам из массива среда выполнения получает элементы массива напрямую, поэтому метод Update () работает с самим элементом массива. Это означает, что обновляются сами структуры в массиве.

Во втором примере мы использовали общий List <> . Что происходит, когда мы получаем доступ к определенному элементу? Итак, вызывается свойство indexer, которое является методом. Типы значений всегда копируются при возврате методом, поэтому происходит именно это: список ' Метод индексатора s извлекает структуру из внутреннего массива и возвращает ее вызывающей стороне. Поскольку это относится к типу значения, будет сделана копия, и для копии будет вызван метод Update (), который, конечно же, не влияет на исходные элементы списка.

Другими словами, всегда проверяйте свои структуры неизменны, потому что вы никогда не знаете, когда будет сделана копия. В большинстве случаев это очевидно, но в некоторых случаях может действительно вас удивить ...