Re: [go-nuts] Re: Semicolons in Go
Ian, thank you for the thoughtful reply. I realized that my last post might have sounded like I was criticizing your post and that definitely wasn't the intention. My apologies. On Monday, April 24, 2017 at 10:48:25 AM UTC-4, Ian Davis wrote: > > With respect, you are tilting at windmills. You replied to an 8 year old > post from the design phase of the language. It's now 2017 and no-one wants > to step back in time to change what has turned out to be a very successful > design. > > You stated in your first message that you "simply won't use the language" > because it doesn't conform to your learned preferences. I hope you > reconsider and adapt to what is ultimately a minor part of learning a new > language. > > Ian > > > On Mon, 24 Apr 2017, at 03:42 PM, john.d...@gmail.com wrote: > > One of the things that I learned early in life is to recognize B.S. when I > see it. My B.S. flag went up first when I read where someone claimed that > "artifacts" are bad and detract from the readability of code. A compact and > well-defined artifact, like the semicolon, makes code *more* readable > because the programmer's intent is crystal clear, whereas removing them > leaves one guessing exactly where a line ends. The rules are considerably > more complex - not to mention vary across languages, than the simple "it > ends at the semicolon" rule. > > Now I read that the programmer's preference is irrelevant (I hope that we > can agree that the programming community consists of individual > programmers!). Well, that flag just shot up again. There's no reason that > an individual's preference can't be respected when he's editing code, even > if way that the code is stored on disk is the same. That's why I > exclusively use TAB characters for indentation - some people prefer to see > 2 spaces per level of structure, I prefer 3 spaces and someone at my > company prefers 8. We get to see what we prefer without requiring any > changes to the code itself. > > So, here's my current thinking about long lines/continuation lines, take > it for what it's worth. There should be no such thing in a language. A long > line should just be a long line, without limit, in the source file. After > all, it's not the compiler that wants to split long lines so that they are > more readable - it's the programmer when using a text editor or code > viewer. Think how much simpler a compiler would be if it could just assume > that a simple (i.e. non-compound) statement always exists on a single line! > It's the editor that should display a single simple statement on multiple > lines on the screen. In fact, the editor could provide visual cues that a > single statement is being displayed on multiple lines on the screen, such > as a light gray background color, underlining, box around it, whatever. The > point is that the individual programmer's personal preference would be used > without affecting the saved format of the code. > > For that to work well, the editor would probably have to understand the > syntax of a statement so that the line splitting will result in something > that the programmer finds readable. I don't know if a current editor that > can do that. But line splitting is something that the compiler should *not* > have to deal with. After all, it's the programmer using an editor that > cares about making long lines readable, not the compiler. > > > -- > 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...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
Re: [go-nuts] Re: Semicolons in Go
Please don't feed this troll. On Mon, Apr 24, 2017 at 10:42 AM,wrote: > One of the things that I learned early in life is to recognize B.S. when I > see it. My B.S. flag went up first when I read where someone claimed that > "artifacts" are bad and detract from the readability of code. A compact and > well-defined artifact, like the semicolon, makes code *more* readable > because the programmer's intent is crystal clear, whereas removing them > leaves one guessing exactly where a line ends. The rules are considerably > more complex - not to mention vary across languages, than the simple "it > ends at the semicolon" rule. > > Now I read that the programmer's preference is irrelevant (I hope that we > can agree that the programming community consists of individual > programmers!). Well, that flag just shot up again. There's no reason that > an individual's preference can't be respected when he's editing code, even > if way that the code is stored on disk is the same. That's why I > exclusively use TAB characters for indentation - some people prefer to see > 2 spaces per level of structure, I prefer 3 spaces and someone at my > company prefers 8. We get to see what we prefer without requiring any > changes to the code itself. > > So, here's my current thinking about long lines/continuation lines, take > it for what it's worth. There should be no such thing in a language. A long > line should just be a long line, without limit, in the source file. After > all, it's not the compiler that wants to split long lines so that they are > more readable - it's the programmer when using a text editor or code > viewer. Think how much simpler a compiler would be if it could just assume > that a simple (i.e. non-compound) statement always exists on a single line! > It's the editor that should display a single simple statement on multiple > lines on the screen. In fact, the editor could provide visual cues that a > single statement is being displayed on multiple lines on the screen, such > as a light gray background color, underlining, box around it, whatever. The > point is that the individual programmer's personal preference would be used > without affecting the saved format of the code. > > For that to work well, the editor would probably have to understand the > syntax of a statement so that the line splitting will result in something > that the programmer finds readable. I don't know if a current editor that > can do that. But line splitting is something that the compiler should *not* > have to deal with. After all, it's the programmer using an editor that > cares about making long lines readable, not the compiler. > > -- > 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. > -- 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.
Re: [go-nuts] Re: Semicolons in Go
I won't. I'm done with this thread. On Mon, Apr 24, 2017 at 10:52 AM David Peacockwrote: > Please don't feed this troll. > > On Mon, Apr 24, 2017 at 10:42 AM, wrote: > >> One of the things that I learned early in life is to recognize B.S. when >> I see it. My B.S. flag went up first when I read where someone claimed that >> "artifacts" are bad and detract from the readability of code. A compact and >> well-defined artifact, like the semicolon, makes code *more* readable >> because the programmer's intent is crystal clear, whereas removing them >> leaves one guessing exactly where a line ends. The rules are considerably >> more complex - not to mention vary across languages, than the simple "it >> ends at the semicolon" rule. >> >> Now I read that the programmer's preference is irrelevant (I hope that we >> can agree that the programming community consists of individual >> programmers!). Well, that flag just shot up again. There's no reason that >> an individual's preference can't be respected when he's editing code, even >> if way that the code is stored on disk is the same. That's why I >> exclusively use TAB characters for indentation - some people prefer to see >> 2 spaces per level of structure, I prefer 3 spaces and someone at my >> company prefers 8. We get to see what we prefer without requiring any >> changes to the code itself. >> >> So, here's my current thinking about long lines/continuation lines, take >> it for what it's worth. There should be no such thing in a language. A long >> line should just be a long line, without limit, in the source file. After >> all, it's not the compiler that wants to split long lines so that they are >> more readable - it's the programmer when using a text editor or code >> viewer. Think how much simpler a compiler would be if it could just assume >> that a simple (i.e. non-compound) statement always exists on a single line! >> It's the editor that should display a single simple statement on multiple >> lines on the screen. In fact, the editor could provide visual cues that a >> single statement is being displayed on multiple lines on the screen, such >> as a light gray background color, underlining, box around it, whatever. The >> point is that the individual programmer's personal preference would be used >> without affecting the saved format of the code. >> >> For that to work well, the editor would probably have to understand the >> syntax of a statement so that the line splitting will result in something >> that the programmer finds readable. I don't know if a current editor that >> can do that. But line splitting is something that the compiler should *not* >> have to deal with. After all, it's the programmer using an editor that >> cares about making long lines readable, not the compiler. >> > -- >> > 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. >> > -- 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.
Re: [go-nuts] Re: Semicolons in Go
With respect, you are tilting at windmills. You replied to an 8 year old post from the design phase of the language. It's now 2017 and no-one wants to step back in time to change what has turned out to be a very successful design. You stated in your first message that you "simply won't use the language" because it doesn't conform to your learned preferences. I hope you reconsider and adapt to what is ultimately a minor part of learning a new language. Ian On Mon, 24 Apr 2017, at 03:42 PM, john.deig...@gmail.com wrote: > One of the things that I learned early in life is to recognize B.S. > when I see it. My B.S. flag went up first when I read where someone > claimed that "artifacts" are bad and detract from the readability of > code. A compact and well-defined artifact, like the semicolon, makes > code *more* readable because the programmer's intent is crystal clear, > whereas removing them leaves one guessing exactly where a line ends. > The rules are considerably more complex - not to mention vary across > languages, than the simple "it ends at the semicolon" rule.> > Now I read that the programmer's preference is irrelevant (I hope that > we can agree that the programming community consists of individual > programmers!). Well, that flag just shot up again. There's no reason > that an individual's preference can't be respected when he's editing > code, even if way that the code is stored on disk is the same. That's > why I exclusively use TAB characters for indentation - some people > prefer to see 2 spaces per level of structure, I prefer 3 spaces and > someone at my company prefers 8. We get to see what we prefer without > requiring any changes to the code itself.> > So, here's my current thinking about long lines/continuation lines, > take it for what it's worth. There should be no such thing in a > language. A long line should just be a long line, without limit, in > the source file. After all, it's not the compiler that wants to split > long lines so that they are more readable - it's the programmer when > using a text editor or code viewer. Think how much simpler a compiler > would be if it could just assume that a simple (i.e. non-compound) > statement always exists on a single line! It's the editor that should > display a single simple statement on multiple lines on the screen. In > fact, the editor could provide visual cues that a single statement is > being displayed on multiple lines on the screen, such as a light gray > background color, underlining, box around it, whatever. The point is > that the individual programmer's personal preference would be used > without affecting the saved format of the code.> > For that to work well, the editor would probably have to understand > the syntax of a statement so that the line splitting will result in > something that the programmer finds readable. I don't know if a > current editor that can do that. But line splitting is something that > the compiler should *not* have to deal with. After all, it's the > programmer using an editor that cares about making long lines > readable, not the compiler.> > -- > 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. -- 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.
Re: [go-nuts] Re: Semicolons in Go
One of the things that I learned early in life is to recognize B.S. when I see it. My B.S. flag went up first when I read where someone claimed that "artifacts" are bad and detract from the readability of code. A compact and well-defined artifact, like the semicolon, makes code *more* readable because the programmer's intent is crystal clear, whereas removing them leaves one guessing exactly where a line ends. The rules are considerably more complex - not to mention vary across languages, than the simple "it ends at the semicolon" rule. Now I read that the programmer's preference is irrelevant (I hope that we can agree that the programming community consists of individual programmers!). Well, that flag just shot up again. There's no reason that an individual's preference can't be respected when he's editing code, even if way that the code is stored on disk is the same. That's why I exclusively use TAB characters for indentation - some people prefer to see 2 spaces per level of structure, I prefer 3 spaces and someone at my company prefers 8. We get to see what we prefer without requiring any changes to the code itself. So, here's my current thinking about long lines/continuation lines, take it for what it's worth. There should be no such thing in a language. A long line should just be a long line, without limit, in the source file. After all, it's not the compiler that wants to split long lines so that they are more readable - it's the programmer when using a text editor or code viewer. Think how much simpler a compiler would be if it could just assume that a simple (i.e. non-compound) statement always exists on a single line! It's the editor that should display a single simple statement on multiple lines on the screen. In fact, the editor could provide visual cues that a single statement is being displayed on multiple lines on the screen, such as a light gray background color, underlining, box around it, whatever. The point is that the individual programmer's personal preference would be used without affecting the saved format of the code. For that to work well, the editor would probably have to understand the syntax of a statement so that the line splitting will result in something that the programmer finds readable. I don't know if a current editor that can do that. But line splitting is something that the compiler should *not* have to deal with. After all, it's the programmer using an editor that cares about making long lines readable, not the compiler. -- 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.
Re: [go-nuts] Re: Semicolons in Go
On 22 April 2017 at 02:59, Matt Hardenwrote: > a = ( b > + c > + d > * e > ) That doesn't work: https://play.golang.org/p/z6HFDK3XRT The usual Go idiom is to leave the operators at the end of the lines: a = b + c + d* e Note that extra-level of identation at the end - the original expression is misleading - at a casual glance, you might think that b+c+d is multiplied by e, but precedence rules means that it doesn't. a = b + c + d + e It's still almost as easy to add or remove a single line - with the exception of the first and last lines. It's kind of a pity that Go produces this an extra level of indent on this though: a = b + c + d + e It would be nice if it produced: a = b + c + d + e There's probably a good reason why it doesn't though, and you can always work around it: a = 0 + b + c + d + e cheers, rog. > > On Thu, Apr 20, 2017 at 1:24 PM John McKown > wrote: >> >> On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones >> wrote: >>> >>> >>> On Thu, Apr 20, 2017 at 8:27 AM, wrote: If I can't format my programs the way I want, and I much prefer putting operators at the beginning of continuation lines for reasons mentioned on this page, and "Perl Best Practices", I simply won't use the language - at least not without implementing a pre-processor. Automatic semicolon inserting is the worst thing about JavaScript. Please make it optional in some way. >>> >>> >>> The die has been cast. It usually takes two weeks for personal preference >>> here to be forgotten. Hope you give it a good chance, as you'll have many >>> positive benefits. >>> >> >> I understand that it is oft-time better to approach a new language on its >> own merits. Just like with a "human" language. You'll never learn language >> ABC if you keep thinking in language DEF. I.e. think in DEF then translate >> to ABC. You'll always end up doing something wrong because each language has >> a different "mind set" or "world view". >> >> Having said the above, this "auto insertion" of a semi-colon is a bother >> to me too. Mainly because I like to write C code something like: >> >> a = b >> + c >> + d >> * e >> ; >> >> So that I can easily insert or remove a single line. This may well be due >> to my advanced age (64!) and the fact that my original language was FORTRAN >> which was punched onto 80 column card stock. The above did waste cards, but >> made program changes very easy. In today's world of "full screen" editors >> which can reformat and even refactor code upon demand, it is a relic of a >> bygone era. >> >> >> >> -- >> "Irrigation of the land with seawater desalinated by fusion power is >> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion >> >> Maranatha! <>< >> John McKown >> >> -- >> 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. > > -- > 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. -- 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.
Re: [go-nuts] Re: Semicolons in Go
a = ( b + c + d * e ) On Thu, Apr 20, 2017 at 1:24 PM John McKownwrote: > On Thu, Apr 20, 2017 at 12:20 PM, Michael Jones > wrote: > >> >> On Thu, Apr 20, 2017 at 8:27 AM, wrote: >> >>> If I can't format my programs the way I want, and I much prefer putting >>> operators at the beginning of continuation lines for reasons mentioned on >>> this page, and "Perl Best Practices", I simply won't use the language - at >>> least not without implementing a pre-processor. Automatic semicolon >>> inserting is the worst thing about JavaScript. Please make it optional in >>> some way. >> >> >> The die has been cast. It usually takes two weeks for personal preference >> here to be forgotten. Hope you give it a good chance, as you'll have many >> positive benefits. >> >> > I understand that it is oft-time better to approach a new language on its > own merits. Just like with a "human" language. You'll never learn language > ABC if you keep thinking in language DEF. I.e. think in DEF then translate > to ABC. You'll always end up doing something wrong because each language > has a different "mind set" or "world view". > > Having said the above, this "auto insertion" of a semi-colon is a bother > to me too. Mainly because I like to write C code something like: > > a = b > + c > + d > * e > ; > > So that I can easily insert or remove a single line. This may well be due > to my advanced age (64!) and the fact that my original language was FORTRAN > which was punched onto 80 column card stock. The above did waste cards, but > made program changes very easy. In today's world of "full screen" editors > which can reformat and even refactor code upon demand, it is a relic of a > bygone era. > > > > -- > "Irrigation of the land with seawater desalinated by fusion power is > ancient. It's called 'rain'." -- Michael McClary, in alt.fusion > > Maranatha! <>< > John McKown > > -- > 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. > -- 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.
Re: [go-nuts] Re: Semicolons in Go
On Thu, Apr 20, 2017 at 12:20 PM, Michael Joneswrote: > > On Thu, Apr 20, 2017 at 8:27 AM, wrote: > >> If I can't format my programs the way I want, and I much prefer putting >> operators at the beginning of continuation lines for reasons mentioned on >> this page, and "Perl Best Practices", I simply won't use the language - at >> least not without implementing a pre-processor. Automatic semicolon >> inserting is the worst thing about JavaScript. Please make it optional in >> some way. > > > The die has been cast. It usually takes two weeks for personal preference > here to be forgotten. Hope you give it a good chance, as you'll have many > positive benefits. > > I understand that it is oft-time better to approach a new language on its own merits. Just like with a "human" language. You'll never learn language ABC if you keep thinking in language DEF. I.e. think in DEF then translate to ABC. You'll always end up doing something wrong because each language has a different "mind set" or "world view". Having said the above, this "auto insertion" of a semi-colon is a bother to me too. Mainly because I like to write C code something like: a = b + c + d * e ; So that I can easily insert or remove a single line. This may well be due to my advanced age (64!) and the fact that my original language was FORTRAN which was punched onto 80 column card stock. The above did waste cards, but made program changes very easy. In today's world of "full screen" editors which can reformat and even refactor code upon demand, it is a relic of a bygone era. -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown -- 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.
[go-nuts] Re: Semicolons in Go
Thank you. On Thursday, April 20, 2017 at 2:04:33 PM UTC-3, John Deighan wrote: > > If I can't format my programs the way I want, and I much prefer putting > operators at the beginning of continuation lines for reasons mentioned on > this page, and "Perl Best Practices", I simply won't use the language > -- 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.
Re: [go-nuts] Re: Semicolons in Go
On Thu, Apr 20, 2017 at 8:27 AM,wrote: > If I can't format my programs the way I want, and I much prefer putting > operators at the beginning of continuation lines for reasons mentioned on > this page, and "Perl Best Practices", I simply won't use the language - at > least not without implementing a pre-processor. Automatic semicolon > inserting is the worst thing about JavaScript. Please make it optional in > some way. The die has been cast. It usually takes two weeks for personal preference here to be forgotten. Hope you give it a good chance, as you'll have many positive benefits. -- Michael T. Jones michael.jo...@gmail.com -- 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.
[go-nuts] Re: Semicolons in Go
If I can't format my programs the way I want, and I much prefer putting operators at the beginning of continuation lines for reasons mentioned on this page, and "Perl Best Practices", I simply won't use the language - at least not without implementing a pre-processor. Automatic semicolon inserting is the worst thing about JavaScript. Please make it optional in some way. On Wednesday, December 9, 2009 at 6:49:52 PM UTC-5, Rob 'Commander' Pike wrote: > > Here is a proposal. > > - rob, for The Go Team > > *Introduction* > > When we started working on Go, we were more concerned with semantics than > syntax, but before long we needed to define the syntax in order to write > programs. One syntactic idea we tried was to reduce the number of > semicolons in the grammar, to make the source code cleaner-looking. We > managed to get rid of many of them, but the grammar became clumsy and hard > to maintain as we worked on the compiler, and we realized we had > overreached. We backed up to a compromise that had optional semicolons in a > few places, a couple of rules about where they go, and a tool (gofmt) to > regularize them. > > Although we acclimated to the rules and were comfortable with them, once > we launched it became clear that they were not really satisfactory. The > compromise didn't seem to fit right with most programmers. The issue needed > to be rethought. > > The language BCPL, an ancestor to B, which is an ancestor to C, had an > interesting approach to semicolons. It can be summarized in two steps. > First, the formal grammar requires semicolons in statement lists. Second, a > lexical (not syntactic) rule inserts semicolons automatically before a > newline when required by the formal grammar. > > In retrospect, had we thought of BCPL's approach at the time, we would > almost certainly have followed its lead. > > We propose to follow it now. > > Appended to this mail is a formal specification of the proposed rules for > semicolons in Go. They can be summarized much as in BCPL, but Go is a > different language so the detailed rules differ; see the specification for > the details. In short: > > - In the formal grammar, semicolons are terminators, as in C. > - A semicolon is automatically inserted by the lexer if a line's last > token is an identifier, a basic literal, or one of the following tokens: > break continue fallthrough return ++ -- ) } > - A semicolon may be omitted before a closing ) or } . > > The upshot is this: given the proposal, most required semicolons are > inserted automatically and thus disappear from Go programs, except in a few > situations such as for loop clauses, where they will continue to separate > the elements of the clause. > > No more optional semicolons, no more rewriting; they're just gone. You can > put them in if you want, but we believe you'll quickly stop and gofmt will > throw them away. > > The code will look much cleaner. > > There are compatibility issues. A few things break with this proposal, but > not many. (When processing the .go files under src/pkg with an updated > parser, most files are accepted under the old and new rules.) > > By far the most important breakage is lexical string concatenation across > newlines, as in > > "hello " > "world" > > Since the language permits + to concatenate strings and constant folding > is done by the compilers, this feature is simply gone from the language; > use a + to concatenate strings. It's not a huge loss because `` strings can > still span newlines. > > With the new rules, a semicolon is mistakenly inserted after the last > element of a multi-line list if the closing parenthesis or brace is on a > separate line: > > f( > a, > b > ) > > To avoid this issue, a trailing comma is now permitted in function calls > and formal parameter lists, as is the case with composite literals already. > > A channel send spanning a newline can accidentally become a receive, as in > > a = b > <-c > > Inserting a semicolon after the b changes the meaning from a non-blocking > send to an assignment followed by a receive. For this transformation to > mislead, however, the types of a, b and c must be very specific: > interface{}, chan interface{} and chan. So a program might break but it is > almost certain never to succeed incorrectly. We are aware of the risk but > believe it is unimportant. > > A similar thing can happen with certain function calls: > > f() > (g()) > > If f() returns a function whose single argument matches the type of a > parenthesized expression such as (g()), this will also erroneously change > meaning. Again, this is so rare we believe it is unimportant. > > Finally, a return statement spanning a newline is broken up into two > statements: > > return > f() > > For this to miscompile, the return statement must be in a function with a > single named result, and the result expression must be