vazio em genéricos C #?

Tenho um método genérico que recebe uma solicitação e fornece uma resposta.

public Tres DoSomething<Tres, Treq>(Tres response, Treq request)
{/*stuff*/}

Mas nem sempre quero uma resposta para minha solicitação e nem sempre quero alimentar os dados da solicitação para obter uma resposta. Também não quero ter que copiar e colar métodos inteiramente para fazer pequenas alterações. O que eu quero é ser capaz de fazer isso:

public Tre DoSomething<Tres>(Tres response)
{
    return DoSomething<Tres, void>(response, null);
}

Isso é viável de alguma maneira? Parece que usar especificamente o vazio não funciona, mas espero encontrar algo análogo.

Você não pode usar void, mas pode usar object: é um pouco inconveniente porque suas supostas voidfunções precisam retornar null, mas se isso unificar seu código, deverá ser um pequeno preço a pagar.

Essa incapacidade de usar voidcomo um tipo de retorno é pelo menos parcialmente responsável por uma divisão entre as famílias Func<...>e Action<...>dos delegados genéricos: se fosse possível retornar void, todos Action<X,Y,Z>se tornariam simples Func<X,Y,Z,void>. Infelizmente, isto não é possível.

Não, infelizmente não. Se voidfosse um tipo "real" (como unitem F # , por exemplo), a vida seria muito mais simples de várias maneiras. Em particular, não precisaríamos das famílias Func<T>e Action<T>- haveria apenas em Func<void>vez de Action, em Func<T, void>vez de Action<T>etc.

Isso também tornaria o async mais simples - não haveria necessidade do Tasktipo não genérico - nós apenas teríamos Task<void>.

Infelizmente, não é assim que funcionam os sistemas do tipo C # ou .NET ...

Aqui está o que você pode fazer. Como @JohnSkeet disse, não há tipo de unidade em C #, então faça você mesmo!

public sealed class ThankYou {
   private ThankYou() { }
   private readonly static ThankYou bye = new ThankYou();
   public static ThankYou Bye { get { return bye; } }
}

Agora você sempre pode usar em Func<..., ThankYou>vez deAction<...>

public ThankYou MethodWithNoResult() {
   /* do things */
   return ThankYou.Bye;
}

Ou use algo já feito pela equipe Rx: http://msdn.microsoft.com/en-us/library/system.reactive.unit%28v=VS.103%29.aspx

Você pode simplesmente usar Objectcomo outros sugeriram. Ou Int32que vi alguma utilidade. Usar Int32introduz um número "fictício" (usar 0), mas pelo menos você não pode colocar nenhum objeto grande e exótico em uma Int32referência (as estruturas são lacradas).

Você também pode escrever seu próprio tipo "vazio":

public sealed class MyVoid
{
  MyVoid()
  {
    throw new InvalidOperationException("Don't instantiate MyVoid.");
  }
}

MyVoidreferências são permitidas (não é uma classe estática), mas só podem ser null. O construtor da instância é privado (e se alguém tentar chamar este construtor privado por meio de reflexão, uma exceção será lançada para eles).

Como as tuplas de valor foram introduzidas (2017, .NET 4.7), talvez seja natural usar a estruturaValueTuple (a tupla 0, a variante não genérica) em vez de uma MyVoid. Sua instância tem um ToString()que retorna "()", por isso parece uma tupla zero. A partir da versão atual do C #, você não pode usar os tokens ()no código para obter uma instância. Você pode usar default(ValueTuple)ou apenas default(quando o tipo pode ser inferido a partir do contexto).

Gosto da ideia de Aleksey Bykov acima, mas poderia ser um pouco simplificada

public sealed class Nothing {
    public static Nothing AtAll { get { return null; } }
}

Como não vejo nenhuma razão aparente para que Nothing.AtAll não pudesse simplesmente dar null

A mesma ideia (ou a de Jeppe Stig Nielsen) também é ótima para uso com classes digitadas.

Por exemplo, se o tipo é usado apenas para descrever os argumentos para um procedimento / função passado como um argumento para algum método, e ele próprio não aceita nenhum argumento.

(Você ainda precisará fazer um invólucro fictício ou permitir um "Nada" opcional. Mas, IMHO, o uso da classe parece bom com myClass <Nada>)

void myProcWithNoArguments(Nothing Dummy){
     myProcWithNoArguments(){
}

ou

void myProcWithNoArguments(Nothing Dummy=null){
    ...
}

void, embora seja um tipo, só é válido como um tipo de retorno de um método.

Não há como contornar essa limitação de void.

O que eu faço atualmente é criar tipos selados personalizados com construtor privado. Isso é melhor do que lançar exceções no c-tor porque você não precisa chegar até o tempo de execução para descobrir que a situação está incorreta. É sutilmente melhor do que retornar uma instância estática, porque você não precisa alocar nem uma vez. É sutilmente melhor do que retornar um null estático porque é menos detalhado no lado da chamada. A única coisa que o chamador pode fazer é fornecer null.

public sealed class Void {
    private Void() { }
}

public sealed class None {
    private None() { }
}