c# - develop - mono project

Usando palabra clave predeterminada en una DLL

Question

Me he encontrado con un problema realmente extraño al usar la palabra clave default en un proyecto DLL. En mi proyecto de DLL (compilado con VS2013) tengo la siguiente clase:

public class BaseClass<T>
{
public T value;
public bool enabled;
public BaseClass ( T value = default(T), bool enabled = true )
{
this.value = value;
this.enabled = enabled;
}
}

Ahora, si uso esto dentro del proyecto DLL, funciona perfectamente. Puedo crear clases que se derivan de esta clase base sin problema. Pero, tan pronto como trato de usar la DLL en otro proyecto (compilado con Mono 2.0.0), derivar de la clase base con un tipo de valor causa un error de compilador. Esta:

public class ChildClass : BaseClass<int>
{
}

causa esto:

Assets / ChildClass.cs (8,14): error CS1502: la mejor coincidencia del método sobrecargado para BaseClass <int> .BaseClass (int, bool) ''tiene algunos argumentos no válidos

Assets / ChildClass.cs (8,14): error CS1503: Argumento #1'' cannot convert la expresión nula'' al tipo `int ''

Sin embargo, la clase base con tipos de valor se puede usar en campos sin problemas:

public class OtherClass
{
public BaseClass<int> baseInt;
}

Miré la DLL usando ILSpy y noté esto:

public class BaseClass<T>
{
public T value;
public bool enabled;
public BaseClass(T value = null, bool enabled = true)
{
this.value = value;
this.enabled = enabled;
}
}

Tenga en cuenta que el default<T> en el constructor se ha reemplazado con null . Esto parece ser la causa del problema, ya que nulo sería un valor no válido para un tipo de valor.

Entonces, ¿qué está pasando aquí?

EDITAR: Como se descubrió en los comentarios, esto no ocurre cuando el segundo proyecto se compila con VS2013 o con versiones más nuevas de Mono.

Answer 1

Esto parece ser un error con el compilador mono pre-3.2.3 (@usr tenía bastante razón en su comentario inicial). El compilador inserta valores de parámetros predeterminados en los metadatos del conjunto como atributos (vea esta respuesta ). Verifiqué que la salida de ilspy es consistente con ildasm que codifica el default(T) a .param [1] = nullref . Sospecho que la convención es que un default(T) genérico default(T) se codifica como nulo y se supone que el compilador consumidor debe saber cómo usarlo. Parece estar relacionado con este problema ; sin embargo, según las fechas, este problema en particular se solucionó un tiempo antes de que se informara.