Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SUGGESTION] Force static functions class members to use static class data members #1349

Open
fro0m opened this issue Dec 17, 2024 · 4 comments

Comments

@fro0m
Copy link

fro0m commented Dec 17, 2024

The problem:
Software developers oftentimes use static class member functions to make the function available in the desired namespace but not actually using a static class member inside this function. This is a misuse of static member functions which cause confusion among software developers who see that function is static but it does not use static class members. Static functions must say definitely that it uses static data by their nature, otherwise it mislead software developers who will read this code. Some would say that this is not critical, but this cause the programming language to be less specific and more confusing at the same time.

The solution proposed:
Consider using static class member functions which do not use static class member an error (ill-formed). Restrict from using static class member functions when they do not actually use a static class members. Give a compile error when software developers try to do such a thing. Limitation: The only exception for such style is using a singleton pattern, so static member function static Class& Class::instance() which instantiates static Class instance; or static Class* instance variable.

Effects of the solution:
Improving language simplicity. Make the language easier to learn. Make software developers to clearly understand that static class member functions always use static data members.

update 1:
Considering comments from @gregmarr and @ljleb .
Using a static class member function just to show that this function relates to a namespace is a problem of classic C++ which I described above. Class != namespace from the language perspective. So 1 thing in a language must mean 1 thing and not other things. If a user wants to use static class member function it would mean that this function uses a class static member. Only 1 meaning, no misunderstanding. If a user wants to use a function under the namespace he moves this function in this namespace. Only 1 meaning, no misunderstanding. This simplifies language.
Review the meaning of static keyword below and you will see that static class member functions are super cohesive with static class member data, so it is kind of defect of classic C++ to let static class member functions to use data which has no relation to static data members.

  1. Static Variables

    Function Scope: When declared within a function, a static variable retains its value between function calls. It is initialized only once, and its lifetime extends throughout the program's execution, unlike automatic variables that are reinitialized with each call1
    4
    .
    Global Scope: Declaring a global variable or function as static limits its visibility to the file in which it is declared, preventing access from other files4
    5
    .

  2. Static Class Members

    Class Scope: A static member of a class is shared among all instances of that class. It exists independently of any class instances and can be accessed using the class name rather than an object instance. This includes both static member variables and static member functions1
    2
    6
    .

  3. Static Storage Duration

    The keyword indicates that a variable has static storage duration, meaning it is allocated for the entire duration of the program. This applies to both static local variables and static class members2
    5
    .

  4. Static Functions

    Functions declared as static within a class cannot access non-static members directly and are meant to operate independently of object instances. They can be called without creating an instance of the class1
    2
    .

@gregmarr
Copy link
Contributor

gregmarr commented Dec 17, 2024

@fro0m Why do you think that this is a problem? Why should a static class member not be able to provide functionality that isn't connected to any particular bit of global data? If your options are a global function, a namespace function, a class static function, or a class member function, which would you pick for these functions? Would you make them namespace functions instead, and why?

Make software developers to clearly understand that static class member functions always use static data members.

I have never heard such a suggestion before.

@ljleb
Copy link

ljleb commented Dec 17, 2024

Thinking in terms of maintenance makes this suggestion appear quite impractical to me.

Let's say that a static function in the code uses a single static class member once. If for any reason, the function doesn't need to use that static member anymore, then there are two options:

  • fake use of other static members to satisfy the compiler
  • move the static function to a different location (and update user code to refer to the new function location)

Both of these options are quite inconvenient and risk making the code less readable, either by adding extraneous code or by forcing code to be located in unexpected places and forcing user code to change for internal implementation details.

@gregmarr
Copy link
Contributor

Using a static class member function just to show that this function relates to a namespace is a problem of classic C++ which I described above.

You didn't describe the problem. You asserted that it was a problem without saying why. You say that it misleads the software developer into making them think that it uses static data, but don't say why they would think that in the first place, or why they would think it's a problem that it doesn't use static data.

Class != namespace from the language perspective. So 1 thing in a language must mean 1 thing and not other things. If a user wants to use static class member function it would mean that this function uses a class static member.

Again, you are asserting this without any reasoning why the only reason to use a static class member function would be to access class static members. If the class static member is public, then you don't even need a static class member function to access it. If we were to follow this idea to its logical conclusion, then it must access a protected or private class static member. If it were just accessing a public class static, then you could move it to an enclosing namespace (which assumes that there IS an enclosing namespace, which isn't required either.)

Only 1 meaning, no misunderstanding. If a user wants to use a function under the namespace he moves this function in this namespace. Only 1 meaning, no misunderstanding. This simplifies language.

I don't agree with this premise. There can be other reasons than accessing static member data for a member function to be a static member. It may access protected or private static member functions that DO access static member data, or even private non-static member functions if it creates a class object. If I want to refactor the implementation of a private static member function to break it up into multiple member functions, and now one of those member functions doesn't directly access any static data, why is that a problem? Why should I have to move that member function out of a class, and then make the member functions it accesses public so I can still access them?

This premise also assumes that every class has member data. Not every class has member data, especially if the class is a base class that just provides interface. There are more differences between class and namespace than "class contains member data". It also has access control, derivation, and a single definition requirement. With namespace, you have no access control, no derivation, and no protection from anyone else opening up the namespace and adding more things to it at any time. In fact, the only thing preventing people from opening namespace std and adding things to it as they want is that the standard says don't do that, except when you absolutely have to because you're implementing a customization point.

@fro0m
Copy link
Author

fro0m commented Dec 26, 2024

@gregmarr thank you for a constructive dialog.
My suggestion partially solving problem of the language complexity which makes the language errors prone and time consuming to work with. imy suggestion simplifies the language which, in my opinion, is overloaded with different mechanics and syntax of expressing a single thing. Actually, this project is mainly about simplifying language. Many agree that complex language makes it hard to write and read that is why I like this great project. I hope, we all can find out more ways to simplify the language. Pablo Picasso famously stated, "Art is the elimination of the unnecessary," emphasizing the importance of simplicity and focus in creativity and life

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants