None of the overloads of kill are callable using argument types:

[Steven Schveighoffer]

On 5/18/20 9:18 PM, Ali Çehreli wrote:
> On 5/18/20 1:11 PM, BoQsc wrote:> I'm trying to kill my own process, but 
> I'm being unsuccessful at the
>  > compilation of the program. It seems that neither getpid nor
>  > thisProcessID returns a correct type value for the kill function.
> 
> Of course, Adam D. Ruppe is right: You can simply return from main() in 
> this case. Or, Pid is given to you for processes that you've spawned.
> 
> Your question brings one of my recent pet peeves in software: the 
> 'private' keyword.[1] In this case, it's Pid's constructor. I wanted to 
> do the following but it failed because the constructor is private:
> 
>    auto p = new Pid(thisProcessID());

This is not a problem with private, but with the choice of the library 
designer.

Being able to define how things are created enables semantic guarantees 
that cannot be enforced if you don't protect data. Encapsulation is not 
a bad thing, but could possibly be misapplied.

In this case, Pid is simply a wrapper around an int or a HANDLE. I'm not 
seeing the purpose to prevent someone from constructing pids from ints 
or native OS handles. So maybe it's something that can be added.

> 
> Ali
> 
> [1] I don't think 'private' keyword ever protected me. I'm pretty sure 
> of it because if I've ever reached for undocumented features of a type 
> or if I've ever used any member, say, having a name starting with '_', I 
> would be sure to be punished in the future if the implementation 
> changed. I know that and I'm sure it's very easy to teach it to 
> beginners. It's too much protecting me from myself.
> 
> On the other hand, there have been multiple cases where 'private' 
> keyword was hiding a useful feature: D runtime's GC statistics (at least 
> in the past), some of std.getopt's parsing functions, etc. Note to self: 
> Think twice before making anything 'private'.
> 

There have been things that were undocumented that we wanted to change 
in phobos, but we had to go through a long deprecation cycle because 
they weren't marked private and changing the name broke some code of 
people who noticed the symbol and used it. So no, it's not a guarantee 
that just not documenting something or naming it badly is going to 
prevent you from having it be considered public API.

-Steve