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 SomeEntity = otherpackage.SomeEntity
func NewSomeEntity(arg1 Arg1, arg2 Arg2, arg3 Arg3, opts ...Opt)
*SomeEntry {
return otherpackage.SomeEntity(arg1, arg2, opts...)
}
compared to
type SomeEntity = otherpackage.SomeEntity
func NewSomeEntity = otherpackage.NewSomeEntity
среда, 5 декабря 2018 г. в 00:14:42 UTC+3, axel.wa...@googlemail.com:
> 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 apart from writing the wrapper).
>
> On Tue, Dec 4, 2018 at 8:34 PM Liam Breck <li...@networkimprov.net> wrote:
>
>> I meant this should work
>>
>> https://play.golang.org/p/w6MBzP9RNdH
>>
>> On Tue, Dec 4, 2018, 11:21 AM messju mohr <li...@lammfellpuschen.de
>> wrote:
>>
>>> 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
>>> > variables.
>>> > On Tue, Dec 4, 2018, 5:40 AM Axel Wagner <[1]
>>> axel.wa...@googlemail.com
>>> > wrote:
>>> >
>>> > 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 Liam Breck <[2]
>>> li...@networkimprov.net>
>>> > wrote:
>>> >
>>> > 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 received this message because you are subscribed to the
>>> Google
>>> > Groups "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from
>>> it, send
>>> > an email to [3]golang-nuts...@googlegroups.com.
>>> > For more options, visit [4]https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> > email to [5]golang-nuts...@googlegroups.com.
>>> > For more options, visit [6]https://groups.google.com/d/optout.
>>> >
>>> > References
>>> >
>>> > Visible links
>>> > 1. mailto:axel.wa...@googlemail.com
>>> > 2. mailto:li...@networkimprov.net
>>> > 3. mailto:golang-nuts...@googlegroups.com
>>> > 4. https://groups.google.com/d/optout
>>> > 5. mailto:golang-nuts...@googlegroups.com
>>> > 6. https://groups.google.com/d/optout
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/9dfb44a1-478a-4018-b8eb-b7df40013e70n%40googlegroups.com.
