I revived this topic, because I have similar problem but with
additional requirements.
I have interface and some classes that inherits from it. Also I
have property two overloads of *set* properties with types int
and Nullable!int
There is listing of code that illustrates funny bug that I had in
my project.
import std.stdio, std.typecons;
interface ListControl
{
@property {
void selValue(int value);
void selValue(Nullable!int value);
}
}
class CheckBoxList: ListControl
{
override @property {
void selValue(int value)
{
writeln("value: int");
}
void selValue(Nullable!int value)
{
writeln("value: Nullable!int");
}
}
}
void main()
{
//Someone considered to make it of byte type
//instead of int to save memory
Nullable!byte myValue; //it is null/uninitialized
//Creating object
auto checkBoxList = new CheckBoxList;
//Let's assign value to our property
//You see that types don't match. But let's imagine that it is a
complicated project
//and class implementation and *myValue* located in different
modules so programmer don't remember right type
checkBoxList.selValue = myValue; //This just silently fails in
runtime without some compile-time error
}
I spend some time to localize it. I know the source of problem,
so if you haven't guessed it I'll explain.
std.typecons.Nullable uses *alias this* to implicitly access
payload of Nullable. I like it, because it makes code shorter and
allows to work with Nullable like it is underlying value (I'm not
sure about how this sentence sounds in English). But... but...
When using it as property it provides TOO MUCH implicit castings
for me where I not expect it be.
So in the listing assignment doesn't call Optional!int overload
of property (types don't match), but instead it implicitly calls
get of Nullable. It's return value is byte. Byte is implicitly
convertible to int. The only problem that myValue has *Null*
state and get fails with assertion.
It is not what programmer wants to see as a result. The worst
case he expects is compile-time error about type mismatch.
But it is not all! In this topic solution to it is to use
cure-all template methods that will help to know *real* type of
*myValue*. But... but... As you see in the example above I want
to have *virtual* methods, that can't be of template nature in D.
So this solution doesn't work there.
Is there in D the other way to say that I want only
direct/explicit (I don't know how express it correctly in
English) type match in virtual property method without using
templates? Is there some *explicit* keyword (I'm joking).
C++11 has explicit keyword but it's purpose is different from
what I'm saying.
It's interesting to see any ideas, because I have doubts of using
Nullable and *alias this* feature because of bugs like this.
