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