Google упрощает контрактное программирование

Правильно понимаю, что «детали» такого контракта нужно прописывать возле каждого метода, где упоминаются часы — принимаются аргументами или возвращаются в результате? Если так, то тип кажется выгоднее — здесь реализация будет инкапсулирована внутри единтсвенного класса.

Меньше текста писать (самое главное), более прозрачная структура, масштабируемость, полиформизм и прочие полезности.

Такой класс лучше сделать неизменяемым (value object).

в c# есть нормальные контракты

а у вас асерты в рантайме бегут?

Впринципе можно использовать и ассерты, но анотации ИМХО более читабельны, в отличие от длинных ассертов, всегда прописаны перед классом/методом/параметром (знаешь где искать), и контрактные аннотации можно использовать для генерирования документации.

Ну и каким образом данный багрепорт подтверждает вашу точку зрения?

В итоге просто предлагается синтаксический сахар для того же ассерта:

int foo()
    pre  ASSUME_EXPR
    post ENSURE_EXPR
  {
    BODY
  }

вместо

  int foo() {
    assert ASSUME_EXPR;
    try {
      BODY
    } finally {
      assert ENSURE_EXPR;
    }
  }

Не вижу тут какой-то действительно принципиальной разницы. Ну другая форма записи немного, но что это меняет по существу? Ну если это на уровне языка сделано – еще ясно зачем, но когда в виде кривого костыля – непостижимо.

Тогда уже можно начать утверждать что в Си невозможно ООП потому что там нет для него синтаксического сахара.

1. Вы бы указывали источник цитирования. Ну ладно есть гугл, это не проблема – download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html

2. Эти два пункта применимы и к Гугловской библиотеке. Если не выдирать их из контекста а посмотреть на причины.

Do not use assertions for argument checking in public methods. Этот пункт обоснован что параетры функции должны 1) проверятся всегда 2) ошибка должна кидать документированное исключение а не любое. Контракты никак не решают пункт 2), да и насчет пункта 1) не уверен.

Кстати в багрепорте почему-то упоминается что сейчас мол приходится повторять такой код:

if (! some_precondition_assertion)
                throw new PreconditionException();

Хотя явно никто не мешает вынести его в отдельную функцию чтоб можно было писать например: check(some_precondition_assertion).

Do not use assertions to do any work that your application requires for correct operation. Это означает что у ассертов не должно быть побочных эффектов. Этот же момент применим и к контрактам. Они тоже не должны иметь побочных эффектов для корректного функционирования кода.

Короче ваш комментарий к сожалению не отстаивает вашу точку зрения.

Увы, документация — не самая сильная наша сторона, ресурсов не хватает.
С птичьего полета подход описан в этом документе из параллельного проекта CTESK. Дополнительную информацию можно поискать на основном сайте.