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


#1

Хотелось бы поднять на форуме тему из #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).

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


#2

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


#3

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


#4

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


#5

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

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


#6

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


#7

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

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

#8

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


#9

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


#10

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


#11

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

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


#12

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


#13

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