Reserved Words In Go

[Oleku Konko]

Hello,

After 3 months with this language an just discovered i could overwrite some built in function.  My question is 

- Is there any concept of reserved words in go

- (If Yes) Why am i able to overwrite this functions  and more

- (If Yes) Is this a good language design Idea / Why

Thanks

[chris dollin]

On 26 November 2013 13:26, Oleku Konko <oleku...@gmail.com> wrote:

Hello,

After 3 months with this language an just discovered i could overwrite some built in function.  My question is 

- Is there any concept of reserved words in go

Yes.

eg: package, import, func, if, for, struct, const, var.

noteg: string, int, new, make, append

 

- (If Yes) Why am i able to overwrite this functions  and more

Built-in functions aren't reserved words. They're just predeclared names.

- (If Yes) Is this a good language design Idea / Why

(a) no point in making reserved words if they're not necessary.

(b) this allows you to use those names for your own purposes,

    even the names you didn't know were built-in.

(c) new predeclared names can be added to Go without changing

    the grammar and breaking existing code that uses those names.

Chris

--
Chris "allusive" Dollin

[Jan Mercl]

On Tue, Nov 26, 2013 at 2:26 PM, Oleku Konko <oleku...@gmail.com> wrote:
> After 3 months with this language an just discovered i could overwrite some
> built in function. My question is
>
> - Is there any concept of reserved words in go

Yes, just check the specs: http://golang.org/ref/spec#Keywords

> - (If Yes) Why am i able to overwrite this functions and more

Because they're not reserved words, but only identifiers predeclared
in the universe scope.

> - (If Yes) Is this a good language design Idea / Why

IMO yes, but note the "O", ie. your preferences may vary and
rationalizing any opinion is not always helpful.

-j

PS: I suggest everyone to read the specs in the first day.

[Kevin Gillette]

On Tuesday, November 26, 2013 6:32:56 AM UTC-7, chris dollin wrote:

(b) this allows you to use those names for your own purposes,

    even the names you didn't know were built-in.

(c) new predeclared names can be added to Go without changing

    the grammar and breaking existing code that uses those names. 

I'd say c is the important one, and because of c, non-shadowing uses can become shadowing uses (e.g. your point b) simply as a result of c.