On Tuesday, September 13, 2016 at 3:50:12 PM UTC+2, Alan Donovan wrote:
>
> On 13 September 2016 at 08:22, Markus Zimmermann <zim...@gmail.com
> <javascript:>> wrote:
>
>> On Monday, September 12, 2016 at 3:41:35 PM UTC+2, adon...@google.com
>> wrote:
>>>
>>> unused constants and types cost nothing at run time. It's not that
>>> simple, of course, because constant and type declarations may be the only
>>> uses of an import of a package whose initialization has some cost; but this
>>> is quite marginal.
>>>
>>
>> The const declaration of my example is inside an unexported function
>> body. It can not be accessed by an import. So, it should really matter only
>> at compile time, right?
>>
>
> Right. The import case I was referring to is this:
>
> import "p"
> func main() {
> const unused = p.K
> }
>
> The unused constant causes p to be an (unnecessary) dependency, which in
> turn causes p.init to be executed.
>
This holds true for every declaration with an initialization, and should be
therefore be no reason to allow such unused constant declarations. There is
also already the official idiom to use the blank identifier as the explicit
package name if someone really needs p.init to be executed.
However, I am referring to the definition of
>> https://golang.org/doc/faq#unused_variables_and_imports which states
>> "... Go refuses to compile programs with unused variables or imports,
>> trading short-term convenience for long-term build speed and program
>> clarity." Which holds true in the same way for an unused const as it does
>> for an unused variable. However, even though it produces the same results,
>> i.e. a new declaration which decreases the program clarity, only the
>> variable declaration is marked.
>>
>
> You are right that the motivation given in the FAQ should apply equally to
> constants and types.
>
Do you think this might be worth bringing up in golang-dev?
Additionally, if an unused constant is compiled into the binary it does
>> also matter to the binary size, even just a little bit.
>
>
> An unused constant is unlikely to affect the size of the final executable
> since in a typical compiler generates code or data for a constant only when
> it is used. It will be present in the intermediate .a files though.
>
--
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.
For more options, visit https://groups.google.com/d/optout.
