Это решение зависит от цели языка программирования.
Для кого вы разрабатываете язык программирования? Вы проектируете это для людей, которые знакомы с производными от c языками? Если это так, то вам, вероятно, следует добавить поддержку null.
В целом, я бы сказал, что вам следует избегать нарушения ожиданий людей, если это не служит определенной цели.
Взять блоки переключателей в C # в качестве примера. Все метки регистра в C # должны иметь явное выражение потока управления в каждой ветви. То есть все они должны заканчиваться либо оператором "break", либо явным переходом. Это означает, что в то время как этот код является законным:
switch(x)
{
case 1:
case 2:
foo;
break;
}
что этот код не будет законным:
switch (x)
{
case 1:
foo();
case 2:
bar();
break;
}
Чтобы создать «провал» из случая 1 в случай 2, необходимо вставить переход, например:
switch (x)
{
case 1:
foo();
goto case 2;
case 2:
bar();
break;
}
Возможно, это что-то, что может нарушить ожидания программистов на C ++, использующих C #. Однако добавление этого ограничения служит цели. Это исключает возможность появления целого класса распространенных ошибок C ++. Это немного увеличивает кривую изучения языка, но в результате программист получает чистую выгоду.
Если ваша цель - разработать язык, предназначенный для программистов на C ++, то удаление нуля, вероятно, нарушит их ожидания. Это приведет к путанице и сделает ваш язык более трудным для изучения. Тогда ключевой вопрос: «какую выгоду они получают»? Или, в качестве альтернативы, «какой вред это причиняет».
Если вы просто пытаетесь создать «сверхмалый язык», который может быть реализован в течение одного семестра, тогда история другая. В этом случае ваша цель не состоит в том, чтобы создать полезный язык, ориентированный на определенный сегмент населения. Вместо этого нужно просто научиться создавать компилятор. В этом случае большая польза от языка поменьше, поэтому стоит исключить ноль.
Итак, резюмируя, я бы сказал, что вы должны:
- Определите ваши цели в создании языка. Для кого предназначен язык, и каковы их потребности.
- Принимайте решение на основе того, что помогает целевым пользователям наилучшим образом достичь своих целей.
Обычно это достаточно ясно дает желаемый результат.
Конечно, если вы явно не сформулируете свои цели проектирования или не можете договориться о том, каковы они, то вы все равно будете спорить. В этом случае, однако, вы все равно обречены.