Curly brace placement
John
func main()
{
}
it's a syntax error.
It appears you must have
func main(){
}
Notice, the curly brace is in the function header.
Is this a bug, or by design? I cannot seem to find this in the
language specification. Perhaps I'm overlooking something.
thanks,
John
Ian Lance Taylor
Nigel Backhurst - I-E-A
Unfortunately John it is by design, though one which is causing a lot of
problems for a lot of people. The Go compile process inserts a
semi-colon at the end of a statement on a line, unless the line is
terminated with a {. So what happens at compile time is that the actual
compile code in your example would read:
func main();
{
}
with the extra semi-colon inserted, which is clearly an error. The only
way to avoid this is to put the opening brace on the same line as the
statement. A coding style that is unacceptable in many areas.
Regards
Nigel
--
Nigel Backhurst MSc BA(Hons) FFA
Information Engineering Associates
14 Deacon Street
Leicester LE2 7EF
Ryanne Dolan
Unacceptable? Ha!
On Jan 29, 2010 10:18 AM, "Nigel Backhurst - I-E-A" <ni...@i-e-a.eu> wrote:
On 29/01/2010 16:08, John wrote:
>
> I've noticed if you do the following:
>
> func main()
> {
>
> }...
John
Now it makes complete sense.
Thanks!
Nigel Backhurst - I-E-A
>
> Unacceptable? Ha!
>
Unfortunately Ryanne that is the case. My particular area of interest
is in Safety Critical Software development practices.
I was hoping that Go could be used in this field, but as the brace rule
makes it impossible to apply one of the standard code
inspection practices in SCS, it is not possible to get Go code through
the code inspection process. Alright, at the moment
this is not an issue, nobody in their right mind would use a language at
this stage of development for SCS work, which almost
certainly means somebody is, but looking a few years ahead Go has a lot
to recommend it for use in SCS work. Unforantely because of this brace
issue there is a serious objection to using Go for SCS.
By the way before people suggest using gofmt to reformat the code, in
SCS you cannot put the code through a formatter after
the sign off code inspection. The signed off code must be compiled as
is. The reason for this is because of the chance, albeit slim,
that the formatter may introduce an error into the code after it has
been checked.
Regards
Nigel
Sverre Rabbelier
On Fri, Jan 29, 2010 at 17:18, Nigel Backhurst - I-E-A <ni...@i-e-a.eu> wrote:
> A coding style that is unacceptable in many areas.
Good thing those areas are all not relevant! This is go, not Java,
C++, or whatever your 'acceptable coding styles' come from. In fact,
the 'acceptable coding style' for go (gofmt) says that you should put
them on the same line.
--
Cheers,
Sverre Rabbelier
Ostsol
statement. If you have a program:
package main
func Empty ()
func main () {
println ("Hello World!")
}
Go compiles this without issue. If you attempt to call Empty you get
the error "undefined: main.Empty", so it appears that Go entirely
ignores function declarations that do not have a body. That is
strange because Go does not ignore unused imports or variable
declarations.
-Ostsol
On Jan 29, 9:16 am, Ian Lance Taylor <i...@google.com> wrote:
Ian Lance Taylor
> I've got to wonder just why an empty function is considered a valid
> statement. If you have a program:
>
> package main
>
> func Empty ()
>
> func main () {
> println ("Hello World!")
> }
>
> Go compiles this without issue. If you attempt to call Empty you get
> the error "undefined: main.Empty", so it appears that Go entirely
> ignores function declarations that do not have a body. That is
> strange because Go does not ignore unused imports or variable
> declarations.
This is a feature which permits writing the function in C or
assembler. Specifically, see src/pkg/runtime/extern.go.
Ian
Ostsol
-Ostsol
Johann Höchtl
Hehe, don't be to harsh but imho SCS is mostly an effectivelly
pointless reassurance for bid invitation and makes mostly no sense
for programming languages where runtime behaviour can not be
guaranteed to be side effect free or can not be formaly proved.
> --
> Cheers,
>
> Sverre Rabbelier
Jessta
>
> Unfortunately John it is by design, though one which is causing a lot of
> problems for a lot of people.
Reading the mailing list, the problems are very minimal. People just
make the assumption that it's like C and once told the correct syntax
there's no problem.
> A coding style that is unacceptable in many areas.
How can anywhere already have a required coding style for Go
that isn't compatible with the syntactic requirements of Go?
- jessta
--
=====================
http://jessta.id.au
Vincent Risi
totally useless.
Peter Bourgon
> Its wonderful to note that word wrap a Go program and it becomes
> totally useless.
In fairness, when you parse this statement as "insert characters
arbitrarily in a Go program and it becomes totally useless" it seems a
little less silly :) And, applies to plenty of other languages, too.
Vincent Risi
entered implicitly for the grammar parser a word wrap would be less
destructive. Oh please bring back the period used in COBOL programs,
ROFL.
On Jan 30, 11:14 am, Peter Bourgon <peterbour...@gmail.com> wrote:
Ostsol
> Its wonderful to note that word wrap a Go program and it becomes
> totally useless.
>
an 80x24 terminal). When you do that there's practically never any
reason to word wrap a program. The issue is that you have to
sometimes be creative when it comes to splitting lines.
Russ Cox
Its wonderful to note that word wrap a Go program and it becomes
totally useless.
Jessta
> Its wonderful to note that word wrap a Go program and it becomes
> totally useless.
It's wonderful to note that gofmt fixes these things.
word wrapping code is uncommon and breaks a lot of languages, but it's
not a problem if you gofmt
- Jessta
--
=====================
http://jessta.id.au
ish
On Jan 30, 6:09 am, Vincent Risi <vincent.r...@gmail.com> wrote:
> ROFL.
That is where you should stay.
-ish
Vincent Risi
is to get rid of semicolons why was a syntax like awk not considered?
What happened to the faithful whack at the end of a line to escape the
newline char? I am just a little disappointed in a lexer that inserts
the missing semicolons and does not go the further step of a simple
lookahead and insists on the draconian use of braces at the back of
the line. I seem to recall a penchant for that other abomination, tab
chars to indent the code. To those who suggest the compile should be
done with a gofmt extra step, please do not expect me to have false
line numbers reported where the errors are in the code I have written.
I will admit to being a little facetious about word wraps. I guess we
can thank the gods we do not code an 8 char id in columns 73-80 and
sequence numbers in columns 1-6, ie we have moved past the card punch
and the Hollerith cards.
Ostsol
no reason to use it during private work. For the record, I do agree
that one's personal coding style should not matter to the compiler,
except where the language syntax affects it (such as with indentation
in Python). One might argue that that is the case in Go, too, but it
does seem silly.
I prefer explicit semicolons or no semicolons at all. For example,
Python needs no semicolons, but that's because all lines end in a
carriage return unless an explicit continuation is inserted. It also
looks to the next line to decide whether a block of code should end
(else/except/finally). It is therefore somewhat unfortunate, in Go,
that opening braces appear as a sort of continuation.
In spite of all of this I have gotten used to Go's coding style and
have even imported it into my C coding practices. Perhaps this is due
to having spent so much time with Python, which is similarly strict.
-Ostsol
Ryanne Dolan
one's personal coding style should not matter to the compiler