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

Однако, чисто теоретически, интересует возможность в будущих версиях дотнета вместо out-параметра подставлять что-то типа defaultValue или специальной "пустой" памяти под переменную. Я вот тут, кстати, ответил, зачем я задал этот вопрос: http://rsdn.ru/forum/dotnet/3501146.1.aspx

Автор:
Дата: 12.08.09

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, samius, Вы писали:

А>Метод Foo2 есть как расширенный так и в классе А.
А>Когда Вы пишете a.Foo2() то какой метод вызывается?
Метод расширение.

А>>>И что выиграли?
S>>Выиграли то, что просил топикстартер. Напоминаю, он не хотел объявлять лишние переменные при вызове методов с out параметрами.

А>Не проще написать Foo1() и Foo2() без параметров в классе А?
Очевидно, это не во власти топикстартера.

Здравствуйте, Ellin, Вы писали:
E>Хотел бы я посмотреть на выражение вашего лица, когда MS это исправит.

Не исправит. По философским соображениям. С# не будет пытаться угадать, что вы имели в виду. Если вы хотите выкинуть ненужное возвращаемое значение — напишите код, который делает именно это.

Здравствуйте, <Аноним>, Вы писали:

А>Да, действительно, предложенный вами вариант делает то, что мне нужно, вполне можно использовать расширения.

А>Однако, чисто теоретически, интересует возможность в будущих версиях дотнета вместо out-параметра подставлять что-то типа defaultValue или специальной "пустой" памяти под переменную. Я вот тут, кстати, ответил, зачем я задал этот вопрос: http://rsdn.ru/forum/dotnet/3501146.1.aspx

Автор:
Дата: 12.08.09

А, такое-то можно сделать хоть сейчас, безо всяких теоретических будущих версий дотнета.
Держи:

public static class Dummy<T>
{
    public static T Value;
}

Применять по необходимости:

Foo1(out Dummy<int>.Value);
Foo2(out Dummy<A>.Value);

Здравствуйте, Sinclair, Вы писали:

S>А, такое-то можно сделать хоть сейчас, безо всяких теоретических будущих версий дотнета.
S>Держи:
S>

S>public static class Dummy<T>
S>{
S>    public static T Value;
S>}
S>

S>Применять по необходимости:
S>

S>Foo1(out Dummy<int>.Value);
S>Foo2(out Dummy<A>.Value);
S>

Я бы к полю добавил [ThreadStatic] атрибут.

Здравствуйте, samius, Вы писали:
S>Я бы к полю добавил [ThreadStatic] атрибут.
А, собсно, зачем? По идее, чтение из него должно быть запрещено — поэтому нам всё равно, сколько потоков сваливают в поле мусор.
Конечно, есть риск, что в Foo делаются предположения о значении переменной в процессе исполнения:

void Foo(out int a)
{
  a=0;
  for (var i = 0; i < 10; i++)
    a += i;
}

Но, вообще говоря, ошибка — именно в Foo, а не в Dummy: нельзя закладываться на то, что у тебя эксклюзивное владение out параметром. С тем же успехом мы могли нарваться на неожиданное поведение и в единственном потоке — если Foo вызывает какой-нибудь callback:

public void Foo(out int a, Predicate<int> breakCondition)
{
  a = 0;
  for(var i=0; !breakCondition(i); i++)
    a += i;
}

....

int crash;
Foo(out crash, i=> {crash = 0; return i>=10;});

Поэтому сам по себе ThreadStatic, имхо, не шибко поможет. Хотя...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:
S>>Я бы к полю добавил [ThreadStatic] атрибут.
S>А, собсно, зачем? По идее, чтение из него должно быть запрещено — поэтому нам всё равно, сколько потоков сваливают в поле мусор.
S>Конечно, есть риск, что в Foo делаются предположения о значении переменной в процессе исполнения:
S>

S>void Foo(out int a)
S>{
S>  a=0;
S>  for (var i = 0; i < 10; i++)
S>    a += i;
S>}
S>

Именно. Внутри метода out параметр выглядит (да и ведет себя) "почти" как обычный параметр и может быть использован как локальная переменная.

S>Но, вообще говоря, ошибка — именно в Foo, а не в Dummy: нельзя закладываться на то, что у тебя эксклюзивное владение out параметром.
Да, нельзя. Но кто об этом задумывается или задумавшись об этом помнит всегда?

S>Поэтому сам по себе ThreadStatic, имхо, не шибко поможет. Хотя...
Я не рассчитываю, что он поможет. Но то что он исключит появление трудноуловимых и не сильновероятных багов — это да.

Вообще, мне идея с Dummy<T> понравилась, но только как ход мысли. Я бы не стал использовать такую штуку в повседневной жизни для экономии на стэке или просто ради удобства.

Здравствуйте, samius, Вы писали:
S>Именно. Внутри метода out параметр выглядит (да и ведет себя) "почти" как обычный параметр и может быть использован как локальная переменная.
S>Да, нельзя. Но кто об этом задумывается или задумавшись об этом помнит всегда?
Хм. Есть в студии фанаты FxCop? Кто мог бы нарулить два рула:
1. Запрет на чтение из Dummy<> переменной (жосткий, всегда)
2. Запрет на чтение out — параметра внутри метода
S>>Поэтому сам по себе ThreadStatic, имхо, не шибко поможет. Хотя...
S>Я не рассчитываю, что он поможет. Но то что он исключит появление трудноуловимых и не сильновероятных багов — это да.
Ок, да. Пожалуй воспроизводимость однопоточных багов достаточно высока — в отличие от многопоточных. Согласен, ThreadStatic поможет.
S>Вообще, мне идея с Dummy<T> понравилась, но только как ход мысли. Я бы не стал использовать такую штуку в повседневной жизни для экономии на стэке или просто ради удобства.
Я бы тоже
Там есть слишком много потенциальных дырок — даже с ThreadStatic.
Пример, который я привел, конечно же клинический.
Но есть значительно более реалистичный сценарий: несколько параметров. Aliasing problem приведёт к тому, что метод запросто может начать наступать сам себе на пятки.
А поскольку сам класс только и полезен, что для использования в методах, где много out-параметров, шансы нарваться на такое достаточно высоки. Особенно замечательно то, что при отсутствии доступа к исходникам метода, понять суть происходящего будет, мягко говоря, затруднительно.

Здравствуйте, Sinclair, Вы писали:

S>2. Запрет на чтение out — параметра внутри метода

Да, это отличный рулез

Здравствуйте, Sinclair, Вы писали:

S>Конечно, есть риск, что в Foo делаются предположения о значении переменной в процессе исполнения:

void Foo (ref int x, ref int y)
{
  x = 1;
  y = 2;
  if (x == 1) {/* интересно, попадем ли мы сюда? */}
}

.....
Foo(ref i, ref i)
....

Общий вывод — при использовании ref и out параметров нельзя быть уверенным ни в чем....

Здравствуйте, xvost, Вы писали:

X>Общий вывод — при использовании ref и out параметров нельзя быть уверенным ни в чем....
Почему? Можно много в чём быть уверенными.

void Foo(ref int x, ref int y)
{
  var x_ = x;
  var y_ = y;
  x_ = 1;
  y_ = 2;
  if (x_ == 1) {/* интересно, попадем ли мы сюда? Капитан Неуверенность */}
  {
    Console.WriteLine("Я думаю, попадём! Капитан Очевидность");
  }
  
  // работа метода типа завершена; пора вернуть результат потомкам
  x = x_;
  y = y_;
  // тут мы, конечно, не можем быть уверены за алиасы. Но это уже caller-проблем, потому что наша логика была изолирована от возможного алиасинга.
}

Здравствуйте, xvost, Вы писали:

X>Общий вывод — при использовании ref и out параметров нельзя быть уверенным ни в чем....

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

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, Sinclair, Вы писали:

S>>Конечно, есть риск, что в Foo делаются предположения о значении переменной в процессе исполнения:

void Foo (ref int x, ref int y)
{
  x = 1;
  y = 2;
  if (x == 1) {/* интересно, попадем ли мы сюда? */}
}

X>Общий вывод — при использовании ref и out параметров нельзя быть уверенным ни в чем....

Используйте их по мере их назначения и не будет проблем.

Код без ref

void Foo(obj a, obj b)
{
  a = b;
  if(a == b) {//Не факт, что Вы и сюда попадете :) }
}

Так что ref и out тут не виноваты

Здравствуйте, xvost, Вы писали:

Относительно сабжа:

out и ref параметры — это ЗЛО

А как, для примера, эффективно реализовать без "out" IDictionary<,>.TryGetValue?

Здравствуйте, _FRED_, Вы писали:

_FR>Относительно сабжа:
_FR>

out и ref параметры — это ЗЛО

_FR>А как, для примера, эффективно реализовать без "out" IDictionary<,>.TryGetValue?

Сам же себе и отвечу: через Option и т.п., но в шарпе нет удобной поддержки для него
Действительно, будь удобная поддержка [в языке] туплов-опшенов, out-ref действительно нужно было бы выбросить хотя бы из употребления.

Здравствуйте, _FRED_, Вы писали:
_FR>А как, для примера, эффективно реализовать без "out" IDictionary<,>.TryGetValue?
Pair<bool, TResult> TryGetValue(TKey key)?

Здравствуйте, Sinclair, Вы писали:

_FR>>А как, для примера, эффективно реализовать без "out" IDictionary<,>.TryGetValue?
S>Pair<bool, TResult> TryGetValue(TKey key)?

Да, так на самом деле тоже неплохо (по сравнению с Option).