Merge pull request #32020 from hashicorp/fix-future-lang-2

Remove future-facing language from docs (WIP)

website/docs/cli/commands/index.mdx

@@ -107,8 +107,7 @@ even when you specify `-chdir=...`:
 ## Shell Tab-completion
 
 If you use either `bash` or `zsh` as your command shell, Terraform can provide
-tab-completion support for all command names and (at this time) _some_ command
-arguments.
+tab-completion support for all command names and some command arguments.
 
 To add the necessary commands to your shell profile, run the following command:
 
@@ -126,9 +125,6 @@ manually in the shell profile, run the following command:
 terraform -uninstall-autocomplete
 ```
 
-Currently not all of Terraform's subcommands have full tab-completion support
-for all arguments. We plan to improve tab-completion coverage over time.
-
 ## Upgrade and Security Bulletin Checks
 
 The Terraform CLI commands interact with the HashiCorp service

website/docs/cli/commands/validate.mdx

@@ -89,7 +89,7 @@ stream. The top-level JSON object will have the following properties:
 
 The nested objects in `diagnostics` have the following properties:
 
-- `severity` (string): A string keyword, currently either `"error"` or
+- `severity` (string): A string keyword, either `"error"` or
   `"warning"`, indicating the diagnostic severity.
 
   The presence of errors causes Terraform to consider a configuration to be
@@ -125,13 +125,11 @@ The nested objects in `diagnostics` have the following properties:
   text. Renderers should then soft-wrap the paragraphs to fit the width of the
   rendering container, but leave the preformatted lines unwrapped.
 
-  Some Terraform detail messages currently contain an approximation of bullet
-  lists using ASCII characters to mark the bullets. This is not currently a
-  contractural formatting convention and so renderers should avoid depending on
+  Some Terraform detail messages contain an approximation of bullet
+  lists using ASCII characters to mark the bullets. This is not a
+  contractural formatting convention, so renderers should avoid depending on
   it and should instead treat those lines as either paragraphs or preformatted
-  text per the rules above. A future version of this format may define some
-  additional rules for processing other text conventions, but will do so within
-  the bounds of the rules above to achieve backward-compatibility.
+  text. Future versions of this format may define additional rules for other text conventions, but will maintain backward compatibility.
 
 - `range` (object): An optional object referencing a portion of the configuration
   source code that the diagnostic message relates to. For errors, this will
@@ -195,9 +193,7 @@ object, has the following properties:
 
 A `start` position is inclusive while an `end` position is exclusive. The
 exact positions used for particular error messages are intended for human
-interpretation only and subject to change in future versions of Terraform due
-either to improvements to the error reporting or changes in implementation
-details of the language parser/evaluator.
+interpretation only.
 
 ### Expression Value
 
@@ -209,8 +205,7 @@ exactly which values are responsible for an error. The object has two properties
 - `traversal` (string): An HCL-like traversal string, such as
   `var.instance_count`. Complex index key values may be elided, so this will
   not always be valid, parseable HCL. The contents of this string are intended
-  to be human-readable and are subject to change in future versions of
-  Terraform.
+  to be human-readable.
 
 - `statement` (string): A short English-language fragment describing the value
   of the expression when the diagnostic was triggered. The contents of this

website/docs/cli/import/importability.mdx

@@ -2,21 +2,15 @@
 page_title: 'Import: Resource Importability'
 description: |-
   Each resource in Terraform must implement some basic logic to become
-  importable. As a result, not all Terraform resources are currently importable.
+  importable. As a result, you cannot import all Terraform resources.
 ---
 
 # Resource Importability
 
 Each resource in Terraform must implement some basic logic to become
-importable. As a result, not all Terraform resources are currently importable.
-For those resources that support import, they are documented at the bottom of
-each resource documentation page, under the Import heading. If you find a
-resource that you want to import and Terraform reports that it is not
-importable, please report an issue in the relevant provider repository.
+importable. As a result, you cannot import not all Terraform resources.
 
-Converting a resource to be importable is also relatively simple, so if
-you're interested in contributing that functionality, the Terraform team
-would be grateful.
+The resources that you can import are documented at the bottom of
+each resource documentation page in the [Terraform Registry](https://registry.terraform.io/). If you have issues importing a resource, report an issue in the relevant provider repository.
 
-To make a resource importable, please see
-[Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).
+To make a resource importable, refer to [Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).

website/docs/cli/import/index.mdx

@@ -9,35 +9,16 @@ description: >-
 
 > **Hands-on:** Try the [Import Terraform Configuration](https://learn.hashicorp.com/tutorials/terraform/state-import?in=terraform/state&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
 
-Terraform can import existing infrastructure resources. This functionality allows you take
-resources you created by some other means and bring them under Terraform
-management.
+Terraform can import existing infrastructure resources. This functionality lets you bring existing resources under Terraform management.
 
-This is a great way to slowly transition infrastructure to Terraform, or
-to be able to be confident that you can use Terraform in the future if it
-potentially doesn't support every feature you need today.
+~> **Warning:** Terraform expects that each remote object is bound to only one resource address. You should import each remote object to only one Terraform resource address. If you import the same object multiple times, Terraform may exhibit unwanted behavior. Refer to [State](/language/state) for more details.
 
-~> Warning: Terraform expects that each remote object it is managing will be
-bound to only one resource address, which is normally guaranteed by Terraform
-itself having created all objects. If you import existing objects into Terraform,
-be careful to import each remote object to only one Terraform resource address.
-If you import the same object multiple times, Terraform may exhibit unwanted
-behavior. For more information on this assumption, see
-[the State section](/language/state).
+## State Only
 
-## Currently State Only
+Terraform import can only import resources into the [state](/language/state). Importing does not generate configuration.
 
-The current implementation of Terraform import can only import resources
-into the [state](/language/state). It does not generate configuration. A future
-version of Terraform will also generate configuration.
-
-Because of this, prior to running `terraform import` it is necessary to write
-manually a `resource` configuration block for the resource, to which the
-imported object will be mapped.
-
-While this may seem tedious, it still gives Terraform users an avenue for
-importing existing resources.
+Before you run `terraform import` you must manually write a `resource` configuration block for the resource. The resource block describes where Terraform should map the imported object.
 
 ## Terraform Cloud
 
-When you use Terraform on the command line with Terraform Cloud, many commands (e.g., `apply`) run inside your Terraform Cloud environment. However, the `import` command runs locally, so it will not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.
+When you use Terraform on the command line with Terraform Cloud, many commands like `apply` run inside your Terraform Cloud environment. However, the `import` command runs locally, so it does not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.

website/docs/cli/install/apt.mdx

@@ -69,7 +69,7 @@ To configure your repository:
 
 ## Supported Architectures
 
-The HashiCorp APT server currently has packages only for the `amd64`
+The HashiCorp APT server has packages only for the `amd64`
 architecture, which is also sometimes known as `x86_64`.
 
 There are no official packages available for other architectures, such as
@@ -78,7 +78,7 @@ There are no official packages available for other architectures, such as
 
 ## Supported Debian and Ubuntu Releases
 
-The HashiCorp APT server currently contains release repositories for the
+The HashiCorp APT server contains release repositories for the
 following distribution releases:
 
 * Debian 9 (`stretch`)

website/docs/cli/install/yum.mdx

@@ -58,7 +58,7 @@ yum install terraform
 
 ## Supported Architectures
 
-The HashiCorp Yum/DNF server currently has packages only for the `x86_64`
+The HashiCorp Yum/DNF server has packages only for the `x86_64`
 architecture, which is also sometimes known as `amd64`.
 
 There are no official packages available for other architectures, such as
@@ -67,7 +67,7 @@ There are no official packages available for other architectures, such as
 
 ## Supported Distribution Releases
 
-The HashiCorp Yum server currently contains release repositories for the
+The HashiCorp Yum server contains release repositories for the
 following distribution releases:
 
 * AmazonLinux 2 and "latest"
@@ -96,8 +96,8 @@ more than one version at a time, and `yum install` or `dnf install` will
 default to selecting the latest version.
 
 It's often necessary to match your Terraform version with what a particular
-configuration is currently expecting. You can use the following command to
-see which versions are currently available in the repository index:
+configuration is currently expecting. Use the following command to
+retrieve the available versions in the repository index:
 
 ```bash
 yum --showduplicate list terraform

website/docs/cli/plugins/index.mdx

@@ -12,8 +12,7 @@ of resources. (For more information about providers, see
 [Providers](/language/providers) in the Terraform
 language docs.)
 
--> **Note:** Providers are currently the only plugin type most Terraform users
-will interact with. Terraform also supports third-party provisioner plugins, but
+-> **Note:** Providers are the only plugin type most Terraform users interact with. Terraform also supports third-party provisioner plugins, but
 we discourage their use.
 
 Terraform downloads and/or installs any providers

website/docs/cli/plugins/signing.mdx

@@ -9,7 +9,7 @@ description: >-
 
 # Plugin Signing
 
-~> **Note** Currently only provider plugins fetched from a registry are authenticated.
+~> **Note** Terraform only authenticates provider plugins fetched from a registry.
 
 Terraform providers installed from the Registry are cryptographically signed, and the signature is verified at time of installation. There are three types of provider signatures, each with different trust implications:
 

website/docs/internals/credentials-helpers.mdx

@@ -140,8 +140,8 @@ stream and then exiting with a non-zero status code.
 
 ## Handling Unsupported Credentials Object Properties
 
-Currently Terraform defines only the `token` property within JSON credentials
-objects, but this format might be extended in future.
+Terraform defines only the `token` property within JSON credentials
+objects.
 
 If a credentials helper is asked to store an object that has any properties
 other than `token` and if it is not able to faithfully retain them then it

website/docs/internals/json-format.mdx

@@ -49,7 +49,7 @@ The JSON output format consists of the following objects and sub-objects:
 
 ## State Representation
 
-Because state does not currently have any significant metadata not covered by the common values representation ([described below](#values-representation)), the `<state-representation>` is straightforward:
+State does not have any significant metadata not included in the common [values representation](#values-representation), so the `<state-representation>` uses the following format:
 
 ```javascript
 {
@@ -61,8 +61,6 @@ Because state does not currently have any significant metadata not covered by th
 }
 ```
 
-The extra wrapping object here will allow for any extension we may need to add in future versions of this format.
-
 ## Plan Representation
 
 A plan consists of a prior state, the configuration that is being applied to that state, and the set of changes Terraform plans to make to achieve that.
@@ -614,7 +612,7 @@ A `<change-representation>` describes the change to the indicated object.
 
 ## Checks Representation
 
-~> **Warning:** The JSON representation of "checks" is currently experimental
+~> **Warning:** The JSON representation of checks is experimental
 and some details may change in future Terraform versions based on feedback,
 even in minor releases of Terraform CLI.
 
@@ -629,8 +627,7 @@ A `<checks-representation>` describes the current state of a checkable object in
       // "kind" specifies what kind of checkable object this is. Different
       // kinds of object will have different additional properties inside the
       // address object, but all kinds include both "kind" and "to_display".
-      // Currently the two valid kinds are "resource" and "output_value", but
-      // additional kinds may be added in future Terraform versions.
+      // The two valid kinds are "resource" and "output_value".
       "kind": "resource",
 
       // "to_display" contains an opaque string representation of the address

website/docs/internals/login-protocol.mdx

@@ -51,14 +51,12 @@ The properties within the discovery object are as follows:
   specific mechanism by which an OAuth server authenticates the request and
   issues an authorization token.
 
-  Terraform CLI currently only supports a single grant type:
+  Terraform CLI supports a single grant type:
 
   * `authz_code`: [authorization code grant](https://tools.ietf.org/html/rfc6749#section-4.1).
     Both the `authz` and `token` properties are required when `authz_code` is
     present.
 
-  Other grant types may be supported in future versions of Terraform CLI,
-  and may impose different requirements on the `authz` and `token` properties.
   If not specified, `grant_types` defaults to `["authz_code"]`.
 
 * `authz` (Required if needed for a given grant type): the server's

website/docs/internals/machine-readable-ui.mdx

@@ -136,7 +136,7 @@ At the end of a plan or before an apply, Terraform will emit a `planned_change`
 - `resource`: object describing the address of the resource to be changed; see [resource object](#resource-object) below for details
 - `previous_resource`: object describing the previous address of the resource, if this change includes a configuration-driven move
 - `action`: the action planned to be taken for the resource. Values: `noop`, `create`, `read`, `update`, `replace`, `delete`, `move`.
-- `reason`: an optional reason for the change, currently only used when the action is `replace` or `delete`. Values:
+- `reason`: an optional reason for the change, only used when the action is `replace` or `delete`. Values:
   - `tainted`: resource was marked as tainted
   - `requested`: user requested that the resource be replaced, for example via the `-replace` plan flag
   - `cannot_update`: changes to configuration force the resource to be deleted and created rather than updated

website/docs/internals/module-registry-protocol.mdx

@@ -147,9 +147,7 @@ $ curl 'https://registry.terraform.io/v1/modules/hashicorp/consul/aws/versions'
 The `modules` array in the response always includes the requested module as the
 first element.
 
-Other elements of this list are not currently used. Third-party implementations
-should always use a single-element list for forward compatiblity with possible
-future extensions to the protocol.
+Terraform does not use the other elements of this list. However, third-party implementations should always use a single-element list for forward compatiblity.
 
 Each returned module has an array of available versions, which Terraform
 matches against any version constraints given in configuration.

website/docs/internals/provider-network-mirror-protocol.mdx

@@ -149,11 +149,7 @@ A successful result is a JSON object containing a single property `versions`,
 which must be a JSON object.
 
 Each of the property names of the `versions` object represents an available
-version number. The property values must be objects, but no properties are
-currently defined for those objects. Future versions of this protocol may
-define optional per-version properties for Terraform to use as installation
-hints, so implementations of the current version should leave those objects
-empty.
+version number. The property values must be objects, but no properties are defined for those objects. We recommend leaving those objects empty for forward compatibility.
 
 Return `404 Not Found` to signal that the mirror does not have a provider
 with the given address.

website/docs/internals/provider-registry-protocol.mdx

@@ -294,11 +294,11 @@ A successful result is a JSON object with the following properties:
   _required_ for describing an individual provider package so that Terraform
   CLI can avoid downloading a package that will not be compatible with it.
 
-* `os` (required): this must currently echo back the `os` parameter from the
-  request. Other possibilities may come in later versions of this protocol.
+* `os` (required): this must echo back the `os` parameter from the
+  request.
 
-* `arch` (required): this must currently echo back the `arch` parameter from the
-  request. Other possibilities may come in later versions of this protocol.
+* `arch` (required): this must echo back the `arch` parameter from the
+  request. 
 
 * `filename` (required): the filename for this provider's zip archive as
   recorded in the "shasums" document, so that Terraform CLI can determine which

website/docs/language/data-sources/index.mdx

@@ -170,9 +170,8 @@ as defined for managed resources, with the same syntax and behavior.
 
 ## Lifecycle Customizations
 
-Data resources do not currently have any customization settings available
-for their lifecycle, but the `lifecycle` nested block is reserved in case
-any are added in future versions.
+Data resources do not have any customization settings available
+for their lifecycle. However, the `lifecycle` block is reserved for future versions.
 
 ## Example
 

website/docs/language/expressions/for.mdx

@@ -127,11 +127,7 @@ using lexical sorting.
 For sets of strings, Terraform sorts the elements by their value, using
 lexical sorting.
 
-For sets of other types, Terraform uses an arbitrary ordering that may change
-in future versions of Terraform. For that reason, we recommend converting the
-result of such an expression to itself be a set so that it's clear elsewhere
-in the configuration that the result is unordered. You can use
-[the `toset` function](/language/functions/toset)
+For sets of other types, Terraform uses an arbitrary ordering that may change in future versions. We recommend converting the expression result into a set to make it clear elsewhere in the configuration that the result is unordered. You can use [the `toset` function](/language/functions/toset)
 to concisely convert a `for` expression result to be of a set type.
 
 ```hcl

website/docs/language/expressions/type-constraints.mdx

@@ -96,9 +96,8 @@ The three kinds of collection type in the Terraform language are:
   for single line maps. A newline between key/value pairs is sufficient
   in multi-line maps.
 
-  Note: although colons are valid delimiters between keys and values,
-  they are currently ignored by `terraform fmt` (whereas `terraform fmt`
-  will attempt vertically align equals signs).
+  -> **Note:** Although colons are valid delimiters between keys and values, `terraform fmt` ignores them. In contrast, `terraform fmt` attempts to vertically align equals signs.
+
 * `set(...)`: a collection of unique values that do not have any secondary
   identifiers or ordering.