Re: [Discussion] "Internal" attribute and warning

On Sat, May 18, 2024 at 9:11 PM Andreas Heigl <andreas@heigl.org> wrote: > > > > Am 18.05.24 um 19:46 schrieb Robert Landers: > > On Sat, May 18, 2024 at 7:38 PM Andreas Heigl <andreas@heigl.org> wrote: > >> > >> Hey all. > >> > >> Am 18.05.24 um 16:00 schrieb Robert Landers: > >>> Hello internals, > >>> > >>> I've been thinking about having an "internal" attribute that will > >>> emit > >>> a warning if called from outside it's left-most namespace. > >>> > >>> It might look something like this: > >>> > >>> namespace MyCompany\PackageA { > >>> #[\Internal] function doStuff() {} > >>> } > >>> > >>> namespace OtherCompany\PackageB { > >>> \MyCompany\PackageA\doStuff(); // warning emitted > >>> } > >>> > >>> namespace MyCompany\PackageB { > >>> \MyCompany\PackageB\doStuff(); // left-most part of namespace > >>> matches, no warning > >>> } > >>> > >>> This would allow for library maintainers to mark internal constructs > >>> as such and provide users with feedback that they are using code that > >>> may be changed without any notice. > >>> > >>> Any thoughts? > >> I do like the idea in general of being able to mark certain things as > >> internal to a certain namespace. > >> > >> My question is more in the direction of: If we are not enforcing > >> breaking the code but merely emit a warning then that is IMO not > >> something that we need to implement on the language level. People will > >> still be able to use the internal method and just ignore the warning. > > > > I guess that depends on what you mean by "break the code." Many people > > turn warnings into exceptions, and for those people this will > > effectively break their code. Some people may choose to ignore it one > > way or another, but that would be up to them. The idea isn't to break > > people's code though, it's to provide a way to mark very-malleable > > APIs in libraries. Maybe, "Internal" is a bad name for this, but it's > > the most logical. > > The trouble I see is that there are two kind of people: Those that care > about such things and those that don't. > > Those that care about such things will already find these issues during > static analysis. > > Those that don't care will not turn errors into exceptions but instead > have error-reporting set to 0 > > That's why I am hesitant in adding this to the engine but instead would > love to see this as part of userland maintained static analyzers. > > Cheers > > Andreas > > -- > ,,, > (o o) > +---------------------------------------------------------ooO-(_)-Ooo-+ > | Andreas Heigl | > | mailto:andreas@heigl.org N > 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org > | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas > | > +---------------------------------------------------------------------+ > | GPG-Key: https://hei.gl/keyandreasheiglorg > | > +---------------------------------------------------------------------+ Hey Andreas, I don't think this is a useful way to look at it. Otherwise, what is the point of making any error or warning? Static analysis is useful, but there's a lot of things it misses, especially when dynamic calls start happening. Robert Landers Software Engineer Utrecht NL