That makes sense, thank you! It does make it a little confusing that a
special case was made for pointers to arrays that violates that rule, but
it's a pretty rare use case anyway.
Thanks for pointing this out, it was driving me crazy.
On Thursday, July 20, 2017 at 2:47:12 AM UTC-4, Lyuben Blag
The EBNF specifies the syntax, not the behavior. EBNF does not indicate the
order *of *evaluation of source code, only the order of characters *in *the
source code.
On Wednesday, July 19, 2017 at 6:59:29 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Jul 19, 2017 at 3:28 PM, >
> wrote:
> >
>
That's fine, though my example was for a pointer to a slice of a
non-pointer type. Regardless of the type of the slice elements, it
evaluates the slice expression first, then the pointer dereference on the
result of the expression.
It's not the behavior that concerns me though, it's that it's *
A question on Stack Overflow led me to carefully examine the spec and I feel
like there may be some detail that's missing - the behavior is easy enough to
work with, but it's effectively undefined according to the language spec.
Specifically, with a variable x of type *[]string for example, *x[0
I'm not sure there's anything go-specific other than libraries and
frameworks; just general good practices. One of the best things I can
recommend to keep microservices from becoming a mess is to treat every
service like it's external:
- Have a well-defined, versioned API contract for each servi
