Empty interface curly brackets

[Starfish]

Why not make the curly brackets on interface{} optional, and make the formatter remove them? 

This would be consistent with how semicolons are treated.

Do-nothing functions and empty structs could also drop brackets.

PS. I've probably missed some fundamental reason why this is a bad idea.

[Jan Mercl]

On Friday, December 30, 2011 12:55:23 PM UTC+1, Starfish wrote:

Why not make the curly brackets on interface{} optional, and make the formatter remove them? 

m1 := map[T]interface{}{} // Valid

m2 := map[T]interface{} // Now invalid. Or "optional" curly brackets removed?

 

This would be consistent with how semicolons are treated.

Semicolons terminate something. Curly brackets enclose something (list of things). I see no relation.

[Lorenzo Stoakes]

On 30 December 2011 11:55, Starfish <ahn...@rocketmail.com> wrote:>
Why not make the curly brackets on interface{} optional, and make the>
formatter remove them?

Perhaps an unimportant aside, but I like the parallel between an empty
set in maths = {}, and interface {} = an interface with empty method
set , meaning any type possessing any method set implements interface
{}.

Also as opposed to a ;, interface{} could be used in the middle of a
line e.g. func foo(bar interface{} ... and thus the rewrite rules
would become considerably more complicated than 'append semicolons to
ends of lines'. What makes that optional is that it is done for you.

Also consider:-

fn := func() interface {
// Some code
}

There'd be an ambiguity between our optional {}'d interface + the code
in the closure.

--
Lorenzo Stoakes
http://www.codegrunt.co.uk

[Starfish]

Considering what you wrote, perhaps the curly braces could be made optional where there is no ambiguity.

[Jan Mercl]

On Friday, December 30, 2011 1:37:40 PM UTC+1, Starfish wrote:

Considering what you wrote, perhaps the curly braces could be made optional where there is no ambiguity.

Ignoring any other introduced outcomes, there's one always left: Writing the string "{}" takes a little time - once. Reading the code and thinking "here I must mentally insert a curly brackets pair" takes also a little time - but N times. Both for the author and for all of other programmers potentially studying/maintaining/debugging/... the original code.

[Aram Hăvărneanu]

Jan Mercl wrote:
> Writing the
> string "{}" takes a little time - once. Reading the code and thinking "here
> I must mentally insert a curly brackets pair" takes also a little time - but
> N times. Both for the author and for all of other programmers potentially
> studying/maintaining/debugging/... the original code.

Yes. Related to this, code is prose, or at least it could be. Most
style rules for writing prose can be applied to code, at least in some
equivalent form.

Write-only languages like APL are fun, in the same way linguistic
riddles are fun, but when you write newspaper articles you use a
different style (or at least newspapers used to do so).

--
Aram Hăvărneanu

[Lorenzo Stoakes]

Quite. A lot of the appeal of go is the taste and restraint of the
language - features really have to carry their weight :)

[Starfish]

Point taken. Let me make one last outline of an idea:

Suppose all empty curly brackets were dropped altogether. We would then have:

m1 := map[T]interface

func f() interface {

  doSomething()

}

Comments?

[Lorenzo Stoakes]

On 30 December 2011 13:21, Starfish <ahn...@rocketmail.com> wrote:
> m1 := map[T]interface
>
> func f() interface {
>   doSomething()
> }

This is still ambiguous - does it return interface{} (in this
scenario, 'interface') or interface { doSomething() }?

[Starfish]

func f() interface {

  ...

  return something

}

[Starfish]

Or maybe,

func f(arg interface) int { ... }

[DisposaBoy]

FYI: a function definition without bracket is already valid code. It marks a function declaration, so it would never work. and introducing something *only* where it's *not* only makes things more ambiguous.

[Lorenzo Stoakes]

Whether you remove empty brace wholesale or not you end up with added
complexity for questionable benefit. In the case of automatic
semicolon insertion you are reducing something you would otherwise
have to type very often, and the insertion itself is unambiguous. In
this proposal you gain a minor reduction in character count and a
possibly increased readability in many ambiguous scenarios which would
probably require special rules both in the compiler and spec.

Just my 2 pence :)

[Liigo Zhuang]

在 2011-12-30 下午9:31，"Starfish" <ahn...@rocketmail.com>写道：
>
> Or maybe,
> func f(arg interface) int { ... }

How about uses a new keyword "anytype" (or variant) ? And we can write:

func f(arg anytype) int { … }

[Krzysztof Kowalik]

you can write:

type variant interface{}

and use it whenever you want...

Btw, imho what go provides so far is definitely enough, if you want to have language which allows you to do the same thing in many different ways then try ruby or javascript :) I like the simplicity and explicit spirit of go syntax.

cheers,

nu7

2011/12/30 Liigo Zhuang <com....@gmail.com>

[Vadik Vygonets]

So the compiler should parse the block before deciding whether it
belongs to the interface or to the function? This way lie undecidable
grammars, madness and C++.

Vadik.