Private visible?

Don Clugston dac at nospam.com.au
Fri Jul 14 03:38:38 PDT 2006


Walter Bright wrote:
> Ivan Senji wrote:
>> Various 'poisoning' techniques sound a lot like C++ to me. There one 
>> can make classes that can not be constructed, can not be inherited 
>> from, can not be passed by value, cannot be allocated on stack and 
>> many different things by making something that is private. But are 
>> these techniques realistic or even possible in D?
> 
> Sometimes it is valuable to be able to say "you can't do this operation 
> with this type". I don't see why this ability should be restricted to C++.

Seems to me that it's a bit of a hack to use private for that purpose.
FWIW, you can also use deprecated{} to poison functions (though of 
course it doesn't work if -d is enabled). Of course this is a hack as 
well, but interestingly it catches internal use of that function, which 
AFAIK 'private' does not.

class Something {
deprecated {
   bool opEquals(Something q) { return false; }
}
}

And if IFTI worked for operators, you could write:

class Something {
   bool opEquals(A) (A q) {
	static assert(0,
      "You can't do == with type Something, because ...");
   }
}



More information about the Digitalmars-d mailing list