Успешно компилируется

variant Color
{
  | Custom { Red : int = 10; } // Ну не хочу я каждый раз задавать все атрибуты
}

Однако:

def color = Color.Custom();

error : wrong number of parameters in call, needed 1, got 0

Здравствуйте, _FRED_, Вы писали:

_FR>

Я переопределял конструктор. Еще, кажется, для вариантов есть что-то типа [RecordIgnore].

Здравствуйте, catbert, Вы писали:

_FR>>

C>Я переопределял конструктор. Еще, кажется, для вариантов есть что-то типа [RecordIgnore].

Конструктор внутри Custom, то есть элемента варианта?

Здравствуйте, _FRED_, Вы писали:

_FR>Успешно компилируется
_FR>

_FR>variant Color
_FR>{
_FR>  | Custom { Red : int = 10; } // Ну не хочу я каждый раз задавать все атрибуты
_FR>}
_FR>

Привет C++:

variant Color
{
  | Custom
  {
    Red : int;

    public this() { this(10) }
  }
}

Здравствуйте, hardcase, Вы писали:

_FR>>Успешно компилируется

_FR>>variant Color
_FR>>{
_FR>>  | Custom { Red : int = 10; } // Ну не хочу я каждый раз задавать все атрибуты
_FR>>}

H>Привет C++:

H>variant Color
H>{
H>  | Custom
H>  {
H>    Red : int;

H>    public this() { this(10) }
H>  }
H>}

Так написать я и на шарпе могу Пример не отвечает на вопрос: что означает "= 10" в коде выше

Здравствуйте, _FRED_, Вы писали:

_FR>Так написать я и на шарпе могу Пример не отвечает на вопрос: что означает "= 10" в коде выше

Значение по умолчанию в поле Red, которое всеравно затирается вызовом конструктора:

public this(red : int)
{
  Red = 10;
  Red = red;
}

Здравствуйте, _FRED_, Вы писали:

_FR>Конструктор внутри Custom, то есть элемента варианта?

Автоматическому конструктору можно снести бошку:

variant Color
{
  | Custom
  {
    Red : int = 10;

    public new this(red : int = 10)
    {
      Red = red;
    }
  }
}

Здравствуйте, hardcase, Вы писали:

_FR>>Конструктор внутри Custom, то есть элемента варианта?

H>Автоматическому конструктору можно снести бошку:

"We need to go deeper"

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

Пока на шарпе реализовал юнион врукопашную, руки устали, клавиатура задымилась… Зато пользоваться удобнее

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, hardcase, Вы писали:

_FR>>>Конструктор внутри Custom, то есть элемента варианта?

H>>Автоматическому конструктору можно снести бошку:

_FR>"We need to go deeper"

Еще есть RecordIgnore, правда в этом случае будут проблемы с PMом.

variant Color
{
  | Custom
  {
    [RecordIgnore] Red : int = 10;
    
    public this(red : int) { Red = red }
  }
}

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

Здравствуйте, hardcase, Вы писали:

H>Как правило, когда требуется некое умолчательное значение для поля просто дописывается нужный конструктор. Ты в праве написать макрос, который бы генерировал такие конструкторы автоматом.

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

Здравствуйте, _FRED_, Вы писали:

_FR>Мне просто не понятно, чем требуемая фича помешает стандартному макросу В данный момент, мне кажется. работа компилятора или макроса — не знаю, не правильная.

Сколько конструкторов будет у следующего случая и каковы будут их сигнатуры:

variant Foo
{
  | X
  {
    a : int -> void = x => WriteLine(x);
    b : int -> void = x => WriteLine(x);
  }
}

Нужно учесть, что в качестве значений по-умолчанию можно использовать лишь примитивные типы.

Здравствуйте, hardcase, Вы писали:

_FR>>Мне просто не понятно, чем требуемая фича помешает стандартному макросу В данный момент, мне кажется. работа компилятора или макроса — не знаю, не правильная.

H>Сколько конструкторов будет у следующего случая и каковы будут их сигнатуры:

H>variant Foo
H>{
H>  | X
H>  {
H>    a : int -> void = x => WriteLine(x);
H>    b : int -> void = x => WriteLine(x);
H>  }
H>}

H>Нужно учесть, что в качестве значений по-умолчанию можно использовать лишь примитивные типы.

А вы сами подумали на этот вопрос? Я вот вижу только один рабочий вариант

Смотрите. Исходя из:
1. Для рекорда конструктор с параметрами для значений полей есть всегда. Это, собственно, один из атрибутов рекорда. когда одно из полей рекорда уже проинициализированно
2. Поля в рекорде, которые пользователь не может задать снаружи нужны или нет? ИМХО, нет: такие поля будут равносильны статическим полям. Поэтому каждое поле рекорда должно мочь задаваться снаружи через параметр конструктора.

Получаю:
1. Есть есть инициализация поля, то выражение инициализации идёт в значение по-умолчанию параметра конструктора. Иначе инициализация не имеет смысла (будет перезатёрта в конструкторе).
2. Если значение инициализации не может быть использовано в качестве значения по-умолчанию, получается ошибка компиляции.
3. У пользователя всегда есть возможность определить собственный конструктор и наинициализировать там всё что ему заблагорассудится.

Поведение "по-умолчанию" в точности описаным образом будет просто и понятно. Пример выше не будет работать — он будет требовать кастомного конструктора (в котором поля инициализируются указанными выражениями) по понятным причинам.

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

Можно придумать правила, которые позволять, например поменять тип параметров для полей a и b в примере выше на опшены и воспользоваться этим для определения того, задан параметр или нет можно, но будет работать не всегда: ести тип самого поля уже опшен, то we need to go deeper

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

Здравствуйте, _FRED_, Вы писали:

_FR>Смотрите. Исходя из:
_FR>1. Для рекорда конструктор с параметрами для значений полей есть всегда. Это, собственно, один из атрибутов рекорда. когда одно из полей рекорда уже проинициализированно
_FR>2. Поля в рекорде, которые пользователь не может задать снаружи нужны или нет? ИМХО, нет: такие поля будут равносильны статическим полям. Поэтому каждое поле рекорда должно мочь задаваться снаружи через параметр конструктора.

_FR>Получаю:
_FR>1. Есть есть инициализация поля, то выражение инициализации идёт в значение по-умолчанию параметра конструктора. Иначе инициализация не имеет смысла (будет перезатёрта в конструкторе).
_FR>2. Если значение инициализации не может быть использовано в качестве значения по-умолчанию, получается ошибка компиляции.
_FR>3. У пользователя всегда есть возможность определить собственный конструктор и наинициализировать там всё что ему заблагорассудится.

Т.е. предложение по улучшению макры Record сводится к тому, что макра должна выражение инициализации поля помещать в опциональное значение параметра конструктора?

Здравствуйте, hardcase, Вы писали:

H>Т.е. предложение по улучшению макры Record сводится к тому, что макра должна выражение инициализации поля помещать в опциональное значение параметра конструктора?

Именно так.

Я вот смотрю, что в декларации автосвойства нельзя дефолтовое значение указать Или я просто не нашёл как?