On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

Some examples of global variables that are frequently used:

1. C has an implicit global variable in all programs - errno.
2. If you are writing asm blocks (in C or D), then the processor's flags and registers are obviously global variables that can affect the function's behavior. At least in D the compiler will complain if a function is marked pure but has an inner asm block; the block has to be annotated explicitly with pure.
3. The language runtime might also be considered as one giant global variable. As an example, a function may return successfully on one invocation and fail on another despite being pure and being invoked with the same parameters, just because a memory allocation has failed. Potentially, you could even catch and handle OurOfMemoryErrors (something which you aren't supposed to do, I think) and change function behavior based on that. However, if I'm not mistaken, any issues related to memory allocation aren't typically considered a part of the function's "contract"; otherwise, pure would only be possible if @nogc is also present.

On Wednesday, 26 January 2022 at 08:07:10 UTC, rempas wrote:

I have the same worries about global mutables as others...

On Wednesday, 26 January 2022 at 09:27:28 UTC, rempas wrote:

The numbers behind the name are roughly the year of the standard. FORTRAN 66 and FORTRAN 77 used all caps. Fortran 90 and later dropped the all caps thing.

Modern Fortran isn't bad if you're working in the domain for which it was written. I wouldn't hesitate to take it over C, C++, or Rust for that type of work.

On Wednesday, 26 January 2022 at 08:02:33 UTC, rempas wrote:

```d
int foo(ref int global)
{
    bar(global);
}
int bar(ref int global);
```
the "outline" (a reduced call graph if you will) would be something like

```
foo(ref int global)
  bar(global);
```
if the code is small enough just post the code, I want to illuminate that if you have a bunch of parameters everywhere you might want to make it a member function instead.

If a class is reasonable, use a class, however if it's just some mutable state then use a struct since you don't need OOP

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

I once worked on a system (written in Java) that was a huge commercial success. The company has a revenue of about €100 million from it. What later turned out should always have been passed on to methods as a parameter was always a global function. Now many person years have been spent on development and countless lines have been written and there is absolutely no way to fix this as the effort in time and money is way to large. For some little programs you might get away with some globals, but not in case of lage systems.

On 1/26/22 4:10 AM, rempas wrote:

A property is a functional setter/getter (or only one of those) that prevents incorrect usage.

For example, if you have a global int, and it really should only be in the range of 1 to 1000, you can guard the setting of the int to make sure that value was correct.

Or if you have a class reference stored globally, you may want to prevent someone from reassigning the class reference to another object. Then you can restrict access to getting only, and not allow setting.

You can implement a property in D at global level, e.g.:

private Resource _resource;

public Resource resource() { return _resource; } // only can access via this property

-Steve

On Wednesday, 26 January 2022 at 11:38:51 UTC, forkit wrote:

What you describe here is actually not specific to globals.
The same can happen with aggregate members

struct S
{
    int e;
    function f() {int e;}
}

but also inheritance. This is more a problem of name hijacking, except that this is officially not recognized as such, since there is a way to distinguish (either using the global access operator or the explicit ThisExp.

Here is an example for the inheritance taken from DMD codebase and that was encountered, for real, 2 years ago while doing a refactoring

class A
{
     bool isscope;
}

class B : A
{
    bool isscope(); // not even related to A.isscope
}

now remember that getters can be called without parens. Now imagine you want to rename one of the isscope.

On Tuesday, 25 January 2022 at 09:53:25 UTC, rempas wrote:

when you create a global variable anything can modify it, meaning that if someone else writes code, or another thread changes the variable, it can cause side affects, and it can be difficult to follow especially because you may not know what or where the bug is, also when you pass it into a function then you are effectively documenting the code, this means in the future it will be much easier to debug because you know where it is going, especially when working in a team environment. however this is yes good practice but I still use global variables when it is convenient for a smaller project where the code fits on one screen, or the name of the variable describes its location. but I work for myself and I am the only one who sees my code.
a lot of code practices people recommend such as not using macros is because of team environments' because many convenient code practices can easily cause confusion for your peers. but I still dont understand why people see it as a sin of coding to use global variables, it depends on the code base and the project.

In some of my code there is only global variables because one of the languages I use only uses global variables so if something is broken it takes a hot minute, I dont know what function is causing the error, just have to go through them all.