Facebook платит за устранение багов в реализации языка программирования D

Ты сам-то как считаешь, должны быть ссылки типами, как в С++, и, соответственно, допускаться в полях объектов, или же, как в D, ссылки должны быть ..эм.. способом обращения, передачи параметров и возврата?

вообще ссылки должны быть типами

но вот более сложный вопрос — а не нужен ли специальный такой подвид ссылок, который может применятся *только* для передачи параметров в функции и возврата значений из них? тут уже я не знаю, но полагаю, что не нужен

понятно, что нужно порасспрашивать, зачем в Д сделали такой вот «способ обращения»

мешает забота о клиенте

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

Я это и пытался объяснить forCe, что между ссылками и указателями по уровню и качеству гарантий нет принципиальных различий. Все различия в головах конкретных разработчиков, не более того.

вообще ссылки должны быть типами

Так ли это необходимо? Вот с указателями все понятно - это типы, у которых есть значения и пр. А вот ссылки...

Изначальную проблему Страуструпа с перегрузкой операторов подход D решает.

А написать так программисту может помешать разве что опыт и здравый смысл.

я согласен насчет опыта, но вот как насчет здравого смысла?!

здравый смысл подсказывает, что аргументы в функцию необходимо передавать с минимально возможными правами; константные ссылки обеспечивают именно такие права, то тут бац! оказывается, компилятор именно для этого случая отключает полезную диагностику, что в здравый смысл как-то не очень укладывается

Так ли это необходимо? Вот с указателями все понятно - это типы, у которых есть значения и пр. А вот ссылки...

Изначальную проблему Страуструпа с перегрузкой операторов подход D решает.

по-моему, тут рассуждать надо с другого конца — перегрузка (не только операторов) должна производится не исходя из сырых типов параметров, а исходя из каким-то образом приготовленных типов

а то ведь можно так договорится, что const со товарищи тоже не должны быть типами и не должны использоваться в полях объектов, а быть только «способом обращения», т.к. const мешает перегрузке и требует нескольких функций

напомни, кстати, в чем суть проблемы Страуструпа?

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

напомни, кстати, в чем суть проблемы Страуструпа?

Я имел в виду, что ссылки в C++ были введены для решения проблемы с перегрузкой операторов, которую очень хотелось сделать в языке, но никак не получалось из-за семантики значений в Си.

const является типом, поскольку ограничивает набор операций... Вполне логично. Кажется, C++-подобных типов-ссылок-синонимов нигде больше нет.

const является типом, поскольку ограничивает набор операций... Вполне логично

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

тут конечно есть разница в том, что ссылка вводит новый синтаксис, но она не очень существенна — можно рассмотреть язык, почти эквивалентный си, у которого инкремент, декремент и произвольные сложения-вычитания производились бы не ++, - - , +=, а .increment, .decrement, .move_by, и произвольные указатели можно было бы использовать без разыменования, почти как сейчас используются указатели на функции:

int a[5]={0, 1, 2, 3, 4};
int* ptr2 = &(a[2]);
int* ptr1 = ptr2.decrement();
ptr2 = &(a[2]);
int* ptr3 = ptr2.increment();
printf("%d", ptr3+ptr1); /* печатает 4, т.е. 3+1 */ 
printf("%d", ptr3+1); /* тоже печатает 4, т.е. 3+1 */ 
printf("%d", ptr3.raw_value()); /* печатает допустим 2384098780, т.е. значение указателя как целого */ 

А что мы делаем с =, ==, !=, <, >, etc.? Что делаем вообще с понятием идентичности? Что делаем с указателем на указатель ... на указатель? Что делаем с типами, у которых есть decrement(), increment() в интерфейсе? Как будет вести себя такой указатель на них?

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