From b8108d4f3c81986f9f0f49472ff129b9cdf7dc78 Mon Sep 17 00:00:00 2001 From: Andrew Gerrand Date: Wed, 8 Oct 2014 13:23:05 +1100 Subject: doc: use "keyed" instead of "tagged" in Go 1 compatibility doc LGTM=bradfitz, r R=r, bradfitz CC=golang-codereviews https://codereview.appspot.com/156730043 --- doc/go1compat.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/go1compat.html b/doc/go1compat.html index 8ceaf32f9..04a6c1124 100644 --- a/doc/go1compat.html +++ b/doc/go1compat.html @@ -83,16 +83,16 @@ break if the bug is fixed. We reserve the right to fix such bugs.
  • Struct literals. For the addition of features in later point releases, it may be necessary to add fields to exported structs in -the API. Code that uses untagged struct literals (such as pkg.T{3, +the API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to create values of these types would fail to compile after -such a change. However, code that uses tagged literals (pkg.T{A: +such a change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"}) will continue to compile after such a change. We will -update such data structures in a way that allows tagged struct -literals to remain compatible, although untagged literals may fail +update such data structures in a way that allows keyed struct +literals to remain compatible, although unkeyed literals may fail to compile. (There are also more intricate cases involving nested data structures or interfaces, but they have the same resolution.) We therefore recommend that composite literals whose type is defined -in a separate package should use the tagged notation. +in a separate package should use the keyed notation.
  • -- cgit v1.2.1