It is pity `func g = othermod.F` were rejected. It could simplify
refactoring.
For example, I've decided to move type and its constructor to other
package. I could easily alias type in its previous place to remain
compatibility, but I have to write ugly wrapper for constructor:
type
This was considered (or rather, the `func g = f` syntax), but ultimately it
was decided that the current ways to forward functions are good enough :)
Either use var, or if you are uncomfortable with having that
*theoretically* mutable, wrap it directly (it should get inlined, so
there's no cost
I meant this should work
https://play.golang.org/p/w6MBzP9RNdH
On Tue, Dec 4, 2018, 11:21 AM messju mohr Erm, function names may be const, but functions are first class citizen
> types and can of course be assigned to variables and be passed around.
>
> just my 2c
>
> On Tue, Dec 04, 2018 at
Erm, function names may be const, but functions are first class citizen types
and can of course be assigned to variables and be passed around.
just my 2c
On Tue, Dec 04, 2018 at 10:27:19AM -0800, Liam Breck wrote:
>Ah yes, var works. But it should be const, since func names aren't
>
Ah yes, var works. But it should be const, since func names aren't
variables.
On Tue, Dec 4, 2018, 5:40 AM Axel Wagner You can use
> var Gi = g.G(int)
> or you can use
> func Gi(i int) error { return g.G(i) }
> for the same effect. Which is pretty much the reason why
> alias-declarations ended
You can use
var Gi = g.G(int)
or you can use
func Gi(i int) error { return g.G(i) }
for the same effect. Which is pretty much the reason why alias-declarations
ended up only be added for types - all other declarations can already be
emulated sufficiently well. :)
On Mon, Dec 3, 2018 at 11:39 PM
Type aliases appear in the contracts draft design. Has anyone suggested
alias declarations for generic functions? This would simplify syntax for
callers...
package g
func G(type T)(i T) error { ... }
---
package main
import "g"
func Gi g.G(int) // declare alias
func f() {
Gi(1)
}
--
You
