ограничить квалификатор функций-членов (ограничить этот указатель)

Либо я что-то упускаю, либо ваш вопрос не имеет смысла. this не этим отличается от любого другого аргумента функции-члена, так почему же вас удивляет, что GCC позволяет вам применять к нему restrict?

Что касается применения его к оператору присваивания, вы справедливо отмечаете, что это устранит необходимость в явном тесте на самоприсваивание. Затем вы говорите:

Очевидно, это то, что вы не можете знать заранее

Но это всегда верно, когда вы используете restrict для чего-либо. Например, кто-то может решить вызвать memcpy с перекрывающимися областями памяти; вы «не можете знать заранее», что они этого не сделают. Но объявление restrict для аргументов memcpy означает, что они совершили ошибку, если они это сделают. Точно так же, если вы объявите оператор присваивания restrict, вы сделаете ошибку для кого-то, кто присваивает себе объекты этого класса. В этом нет ничего таинственного или противоречивого; это просто часть семантики restrict, которая накладывает определенные ограничения на остальную часть вашего кода.

Я также не уверен, почему вы считаете невозможным для функции-члена получить указатель (или ссылку) на другой объект того же типа. Тривиальный пример:

class Point {
public:
    double distance(const Point &other) const;
};

Такое постоянно всплывает.

Итак, реальный вопрос в том, почему, по-вашему, this так отличается от любого другого аргумента? Или, если хотите, как я так упустил из виду вашу мысль?

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

struct some_class {
    int some_value;

    void compute_something(int& result) {
        result = 2*some_value;
        ...
        result -= some_value;
    }
}

Вероятно, можно было бы ожидать, что для компиляции

*(this + offsetof(some_value)) -> register1
2*register1 -> register2
...
register2 - register1 -> result

К сожалению, этот код будет неправильным, если кто-то передаст ссылку на some_value для результата. Таким образом, компилятор фактически должен был бы сгенерировать следующий

*(this + offsetof(some_value)) -> register1
2*register1 -> register2
register2 -> result

...
*(this + offsetof(some_value)) -> register1
result -> register2
register2 - register1 -> register2
register2 -> result

что, очевидно, менее эффективно. Обратите внимание, что, если только calculate_something не является встроенным, у компилятора нет способа узнать, может ли результат быть псевдонимом some_value или нет, поэтому он должен предполагать наихудший случай, независимо от того, какой умный или тупой это. Таким образом, существует определенное и очень реальное преимущество для ограничения, даже если оно применяется к указателю this.

Ссылка, которую вы разместили, интересна. Не будет надежного варианта использования применения restrict к this. Как вы упомянули в своем вопросе, копирующий конструктор, оператор = могли быть потенциальными кандидатами; но компилятор может позаботиться о них.

Но следующий случай может быть интересным

struct A
{
  //...
  void Destroy (A*& p) __restrict__
  {
    delete this;
    p = 0;
    p++;
  }
};

Теперь вариант использования может быть;

A **pp = new A*[10];
for(int i = 0; i < 10; i++)
  pp[i] = new A;
//...
A* p = pp[0];
for(int i = 0; i < 10; i++)
  p->Destroy(p);
delete[] pp;

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

Боюсь, я не совсем понимаю, почему вы говорите о this.

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

Итак, что может быть в случае, когда действительно нужно дать члену квалификатор ограничения и где это имеет смысл?

Достаточно вспомнить типичный случай использования указателей restrict в memcpy:

void Foo::MyCompute(__restrict__ char* bufA, __restrict__ char* BufB)
{
}

Добавив это как ответ, потому что он, вероятно, лучше подходит как таковой (это своего рода ответ и на самом деле не относится к вопросу, плюс он немного длинный для комментария).

После долгого размышления над ответом Немо я пришел к выводу, что обе наши интерпретации самоназначения, возможно, несколько неверны (хотя Немо был более правильным, чем мой). Как правильно заметил Немо, наличие this с ограничением на самом деле означает, что наличие псевдонимов является ошибкой программы. Ни больше ни меньше.

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

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