> The only real downsides, I think, are that compiler errors gets harder to
read:
> https://github.com/golang/go/issues/21866
> And likewise, that the name won't appear at runtime, so if you print
things using `reflect`, the result will be less readable.
> ...
> https://github.com/golang/go/issues/8082
Yeah, those are the downsides I am familiar with. The reflect I have no
issue with, the compiler errors is a bit more unfortunate. I wasn't aware
of those proposals, though looking at their dates they are not being
actively considered.
Does it have performance implications? Is there any difference in type
resolution for typed interfaces vs untyped ones?
On Tuesday, September 8, 2020 at 12:15:42 PM UTC+2 Javier Zunzunegui wrote:
> > So yes: Using a type alias has advantages, but no, this advantage is
> never realized because neither the alias nor the plain type decl are used
> in practice.
>
> The ResonseWriter is a bad example because it has a method `Header()
> http.Header`, for which you must import net/http regardless.
> Take fmt.Stringer, `type Stringer interface { String() string }`. I could
> perfectly well define `type MyStringer interface { String() string }` and
> use that instead of fmt.Stringer (if fmt.Stringer were an alias, with much
> more flexibility), and avoid importing fmt altogether. And even this
> scenario is trivial (I have nothing agaist importing fmt!), but for my own
> interfaces having the interface defined in separate places can help avoid
> import cycles, make packages more locally contained, keep compilation
> faster, etc.
>
> Hence why I'm asking for reasons against it. I have used this before and
> it has served me well, so I know there are advantages.
>
> On Tuesday, September 8, 2020 at 11:41:25 AM UTC+2 Volker Dobler wrote:
>
>> In practice you never declare the same interface twice
>> switch from one to the other. Why would anybody declare
>> his own ResonseWriter interface if net/http.ResponseWriter
>> exists?
>>
>> So yes: Using a type alias has advantages, but no, this
>> advantage is never realized because neither the alias nor
>> the plain type decl are used in practice.
>>
>> V.
>>
>> On Tuesday, 8 September 2020 at 10:13:23 UTC+2 Javier Zunzunegui wrote:
>>
>>> TLDR: Why should I NOT the alias form `type ... = interface {...}`
>>> instead of the standard `type ... interface {...}` for interface
>>> declarations?
>>>
>>> The extended question:
>>>
>>> The normal type definition for an interface in go would be `type
>>> TypeName interface {...}`. This results in a new type, which is assignable
>>> to other types of the similar interfacce, such that this is valid:
>>> ```
>>> type I1 interface{ Foo() }
>>> type I2 interface{ Foo() }
>>> var _ I1 = I2(nil)
>>> ```
>>> But these are different types, such that any function with one of these
>>> in the signature can't be converted to a similar function with the other,
>>> such that this is NOT valid:
>>> ```
>>> var _ func(I1) = (func(I2))(nil)
>>> ```
>>>
>>> Declare the types as aliases <https://yourbasic.org/golang/type-alias/>
>>> however,
>>> and the limitation dissapears:
>>> ```
>>> type I1 interface{ Foo() }
>>> type I2 interface{ Foo() }
>>> var _ I1 = I2(nil) // still valid
>>> var _ func(I1) = (func(I2))(nil) // now valid
>>> ```
>>>
>>> A runnable example of the below using `http.ResponseWriter`:
>>>
>>> - without alias <https://play.golang.org/p/dKdh80LNMt0>
>>> - with alias <https://play.golang.org/p/sR5hB0ParA0>
>>>
>>> My point being using aliases offers an advantage (more flexible
>>> assignment and interface implementation) and to my knowledge no meaningful
>>> drawback. So why not use it everywhere?
>>>
>>
--
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/51fa50f1-afcc-4694-ae80-254c4630b89an%40googlegroups.com.
