'A' как char и string сразу

Хотелось бы поднять на форуме тему из #724.

Вопрос состоял в том, что компилятор считает что в Arr('a', 'b', 'cd'), 'a' - это обязательно char, и поэтому он не может сам подобрать тип T. Это доставляет ещё больше проблем в case:

begin
  case 'abc' of
    'ab': ;
    'bc': ;
    'b': ;//Ошибка: Нельзя преобразовать тип char к string
  end;
end.

Единственный способ исправить это:

begin
  case 'abc' of
    'ab': ;
    'bc': ;
    string('b'): ;
  end;
end.

Вот только это очень сильно бьёт по читабельности, основной причине использовать тут case а не цепочку из нескольких if then else.

Ну, и так же это не работает у чисел - Arr(1,2,int64(3)) (хотя, кстати, на момент открытия той issue ещё работало).

Я считая что в данном случае надо давать для 'a', 1 и т.п. особый тип, который может восприниматься как несколько разных. У 'a' это char и string, а у 1 это все типы чисел.
В случае же, когда с такими типами остаётся несколько вариантов (как в Arr(1,2,3) ) - выбирать значение по умолчанию (к примеру для чисел - integer, или если не получается - real).

Кто что думает по этому поводу?

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

1 лайк

Согласен, но только для этого случая. Что будет, если будет выбор между двумя методами с одинаковыми названиями и количеством параметров, но разными типами(параметров)?

А Вы посмотрите, как в C#

Да, я знаю как в C#. Там этих проблем и не может возникнуть, потому что если надо A типа char - это 'A', а если типа string - это "A". Это как раз тот случай, когда на C# не надо равняться, потому что базовые возможности отличаются.

Я говорю что надо хотя бы case исправить, но сахар позволяющий компилировать Arr(1,2,int64(3)) был бы не лишним. А по case не спешу issue открывать, потому что если всё же сделать сахар для Arr(1,2,int64(3)) - case сам исправится.

У нас всё ровно так же. Если это A, т.е. один символ в апострофах, то это char, если ноль или больше 1, - то string

Нет, не так же. "A" в C# это один символ, но не char а string. А в паскале чтоб был string из 1 символа приходится извращаться: string('A'). Повторюсь, это делает `case ужасно неудобным:

case 'abc' of
  'ab': ;
  'bc': ;
  string('b'): ;
end;

Да, там тип вычисляется по первой метке

Не хотелось бы снова вспоминать C#, но там для символа и строки разные кавычки. И никаких спорных моментов.

Прошу заметить, что вы меня не слышите. В Паскале тоже нет никаких спорных моментов. Одиночный символ в кавычках - char, ноль, два и более - string. И никаких спорных моментов. Это конечно может не нравиться как отсутствие return. Но таков язык.

return и result не бывают нужны одновременно. В случае же с тем как воспринимать 'A' - бывают нужны оба варианта.

И, ещё раз, это не просто абстрактное “а может понадобится воспринимать его как string” когда то. Это вполне реально, здесь и сейчас ломает case. А вы всё продолжаете игнорировать проблему из этого примера.

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

Я не говорю о том, как воспринимать ‘A’. Я говорю о том, что согласно стандарту языка это тип char. Конечно, это кому-то может мешать