[t43562]

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot.

I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting services and have something that operates in a simple and predictable manner like C includes and include paths (although obviously I don't like preprocessing so not that).

As for the language, I like the range reference idea but my own minor pet peeve is an issue with pre-assignment in if-statements etc which makes a neat feature almost useless:

  // This is nice because err only exists within the if so we don't have to 
  // reuse a variable or invent new names both of which are untidy and have potential 
  // to cause errors (esp when copy-pasting):
  if err := someoperation(); err != nil; {
    // Handle the error
  }


  // This however won't work:  
  func doThing() string {    
     result := "OK" 
     
      if result, err := somethingelse(); err != nil { // result does not need to be created but err does so we cannot do this.
          return "ERROR"  
      }
    

   return result
  }

I don't have any good ideas about how to change the syntax unfortunately.

[fastest963]

You should be able to use "replace" to use your forked module instead of the original and you don't have to change anything.

[jatone]

unfortunately replace is not supported well with modules. and they are hell bent on not supporting it well.

[cube2222]

I've been doing forks of modules and using replace to use them in my code base extensively. I had 0 problems, it works marvelously.

If you're doing some kind of global find/replace on fork, then something's definitely not right.

[lanstin]

Yeah it works fine. It also allows local co-development of the module and its user without waiting for new versions to be noticed

[jatone]

yes that is one approach. it shouldn't be necessary.

[infogulch]

You mean this?

https://thewebivore.com/using-replace-in-go-mod-to-point-to-...

[jatone]

yes. now try to go install your application with the replace directive. it will silently replace the code with the original upstream version.

[usrbinbash]

Easily fixed using lexical scopes:

    func doThing() string {
        result := "OK"

        {
            var err error
            if result, err = somethingElse(); err != nil {
                return "ERROR"
            }
        }

        return result
    }

`err` is introduced in the lexical scope, `result` isn't so it still refers to the string from the surrounding scope. `err` does not pollute the surrounding scope.

You can also try the complete version here: https://go.dev/play/p/kDEB11YdvSs

[travisd]

In my experience this isn’t idiomatic Go and would definitely turn heads in a code review. But in such a small function, it’s fine to just not worry about the lifetime of your variables (and in bigger functions you can often decompose into smaller functions).

[usrbinbash]

I agree. The idiomatic thing here would be to simply declare `var err error` in the surrounding scope, especially since this example is a small function where this wouldn't matter.

But "idiomatic" always takes a backseat compared to technical necessity. If there is a requirement, for some reason, to limit the scope of `err` and still allow `result` to be changed in the if's pre-assignment, then this is the way to do it.

[assbuttbuttass]

The fix is pretty simple, just declare err ahead of time:

    func doThing() string {    
        result := "OK"
        var err error
        if result, err = somethingelse(); err != nil {
            return "ERROR"  
        }

        return result
    }

[rocqua]

Part of the reason OP liked the `if assignment` was to avoid polluting the higher-level scope with a variable that is only needed during the if statement.

Your solution fixes the error, but at the cost of losing the upside OP saw.

[jaggederest]

Is there no equivalent to a lexical scope let definition?

let {

  var err := error
  
  scoped code

}

[usrbinbash]

Of course there is:

    {
        var err error
        scoped code
    }

[ptomato]

yes, you can wrap code in {} to scope it.

[Gwypaas]

The issue is now you have a potential nil value hanging around in the code with no real reason for its existence. Three refactors and some moving around later and you manage to hit a runtime panic in production.

[jatone]

yeah it sucks, I think IDEs should help here. 1 click uplift var error to parent scope.