An idiom for disabling implicit conversions

[Uranuz via Digitalmars-d]

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.