{"action":"created","issue":{"url":"https://api.github.com/repos/toml-lang/toml/issues/525","repository_url":"https://api.github.com/repos/toml-lang/toml","labels_url":"https://api.github.com/repos/toml-lang/toml/issues/525/labels{/name}","comments_url":"https://api.github.com/repos/toml-lang/toml/issues/525/comments","events_url":"https://api.github.com/repos/toml-lang/toml/issues/525/events","html_url":"https://github.com/toml-lang/toml/issues/525","id":301264786,"node_id":"MDU6SXNzdWUzMDEyNjQ3ODY=","number":525,"title":"Proposal: Extended table value assignments","user":{"login":"eksortso","id":1184444,"node_id":"MDQ6VXNlcjExODQ0NDQ=","avatar_url":"https://avatars2.githubusercontent.com/u/1184444?v=4","gravatar_id":"","url":"https://api.github.com/users/eksortso","html_url":"https://github.com/eksortso","followers_url":"https://api.github.com/users/eksortso/followers","following_url":"https://api.github.com/users/eksortso/following{/other_user}","gists_url":"https://api.github.com/users/eksortso/gists{/gist_id}","starred_url":"https://api.github.com/users/eksortso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eksortso/subscriptions","organizations_url":"https://api.github.com/users/eksortso/orgs","repos_url":"https://api.github.com/users/eksortso/repos","events_url":"https://api.github.com/users/eksortso/events{/privacy}","received_events_url":"https://api.github.com/users/eksortso/received_events","type":"User","site_admin":false},"labels":[{"id":941390176,"node_id":"MDU6TGFiZWw5NDEzOTAxNzY=","url":"https://api.github.com/repos/toml-lang/toml/labels/new-syntax","name":"new-syntax","color":"fbca04","default":false},{"id":109644779,"node_id":"MDU6TGFiZWwxMDk2NDQ3Nzk=","url":"https://api.github.com/repos/toml-lang/toml/labels/post-1.0","name":"post-1.0","color":"0e8a16","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-03-01T03:22:54Z","updated_at":"2018-07-03T01:44:57Z","closed_at":null,"author_association":"NONE","body":"In issue #516, we have been considering whether to allow newlines in inline tables. I have been arguing against that as being much too JSON-like.\r\n\r\nBut there does exist a real need, found in the wild, for tables to be defined, mid-section, in order to maintain a configuration file's logical flow with a minimal amount of repetition.\r\n\r\nTo rectify these issues, I propose (while closing #516) that we allow for an _extended_ table value syntax, with the same scope and purpose as _inline_ table value syntax. In essence, it would resemble a section filled with key/value assignments, but assigned to a key or included as an array element. This would maintain TOML syntax consistency, while keeping key lengths short. This would come with limitations, which will be explained. The syntax is compatible with TOML v0.4.0, and could be merged into v1.0.\r\n\r\n## The Proposal\r\nHere, `table_key3` is assigned a table using an _extended table_.\r\n```toml\r\n[section_table]\r\nkey1 = \"value1\"\r\nkey2 = \"value2\"\r\n# For extended tables, a line must end with a left brace, with optional whitespace and comment.\r\ntable_key3 = {\r\n    # The lines between braces must resemble standard key/value pairs. Notice\r\n    # that unlike inline tables, commas are NOT permitted. Also notice that\r\n    # section headers are NOT permitted.\r\n    subkeyA = \"table_key3.value3A\"\r\n    subkeyB = \"table_key3.value3B\"\r\n    subkeyC = \"table_key3.value3C\"\r\n    # Inline table values and dotted key paths are allowed.\r\n    subkeyZ = {inner_key = \"table_key3.inner_value\"}\r\n    subkey_0.subsubkey_0 = \"table_key3.subkey_0.subsubvalue_0\"\r\n# To close an extended table, A line beginning with (optional whitespace and) a\r\n# right brace must be provided.\r\n}\r\n# Assignments to the section table may resume afterwards.\r\nkey4 = \"value4\"\r\n```\r\n\r\nLike inline tables, per the discussion on table definition scope in #499, everything pertaining to the extended table must be found between the braces. And nothing outside the braces may inject key values or subtables into the extended table. For parsing purposes, an extended table opens on the line with the left brace and closes on the line with the right brace.\r\n\r\n## Examples\r\nConsider these two real examples, which I'm paraphrasing from #516.\r\n\r\n**Example 1:**\r\nThis example comes from @seeruk, who transcribed a YAML configuration into TOML. I've removed unneeded section headers and reduced arrays to single lines to save space, and I'm only including the part that pertains to my proposal.\r\n```toml\r\n# Example 1 (original)\r\nversion = \"3\"\r\n\r\n  [services.elasticsearch]\r\n  container_name = \"metrics_elasticsearch\"\r\n  image = \"docker.elastic.co/elasticsearch/elasticsearch:5.5.3\"\r\n  network_mode = \"host\"\r\n  ports = [ \"9200:9200\", \"9300:9300\" ]\r\n  volumes = [ \"elasticsearch-data:/usr/share/elasticsearch/data\" ]\r\n\r\n    [services.elasticsearch.environment]\r\n    \"discovery.type\" = \"single-node\"\r\n    \"http.cors.enabled\" = true\r\n    \"http.cors.allow-origin\" = \"*\"\r\n    \"xpack.security.enabled\" = false\r\n```\r\n\r\nThe problem that @seeruk had with this was: \"That extra level of nesting _[i.e. `services.elasticsearch.environment`]_ just makes TOML that much less nice to use in this case. If the environment could be on the same level as the rest of the service configuration it'd tidy it right up.\" _(Emphasis mine.)_\r\n\r\nNow consider the following, which uses an extended table to put `environment` in the same place as its source:\r\n```toml\r\n# Example 1 with an extended table\r\nversion = \"3\"\r\n\r\n  [services.elasticsearch]\r\n  container_name = \"metrics_elasticsearch\"\r\n  image = \"docker.elastic.co/elasticsearch/elasticsearch:5.5.3\"\r\n  network_mode = \"host\"\r\n  environment = {\r\n    \"discovery.type\"         = \"single-node\"\r\n    \"http.cors.enabled\"      = true\r\n    \"http.cors.allow-origin\" = \"*\"\r\n    \"xpack.security.enabled\" = false\r\n  }\r\n  ports = [ \"9200:9200\", \"9300:9300\" ]\r\n  volumes = [ \"elasticsearch-data:/usr/share/elasticsearch/data\" ]\r\n```\r\n\r\nNotice that `environment` is kept in the midst of the keys in `[services.elasticsearch]`, below `network_mode` and above `ports`. This is important, because you lose something by moving the definition of `services.elasticsearch.environment` outside of `[services.elasticsearch]`.\r\nAlso notice that each line within the braces is just a simple key/value pair. No extra commas required.\r\n\r\n**Example 2:**\r\nExtended tables can also be used in arrays of tables. This example comes from @JelteF, whose company prohibits the use of table arrays due to their confusing syntax. He's repeatedly insisted that inline tables must allow both newlines and commas to resolve his problems, and I've argued against that as being too JSON-like.\r\n\r\nHere's the document, conforming to TOML 0.4.0, that has caused him trouble at his workplace.\r\n```toml\r\n# Example 2 (original)\r\n[main_app.general_settings.logging]\r\nlog-lib = \"logrus\"\r\n\r\n[[main_app.general_settings.logging.handlers]]\r\n    name = \"default\"\r\n    output = \"stdout\"\r\n    level = \"info\"\r\n\r\n[[main_app.general_settings.logging.handlers]]\r\n    name = \"stderr\"\r\n    output = \"stderr\"\r\n    level = \"error\"\r\n\r\n[[main_app.general_settings.logging.handlers]]\r\n    name = \"http-access\"\r\n    output = \"/var/log/access.log\"\r\n    level = \"info\"\r\n\r\n[[main_app.general_settings.logging.loggers]]\r\n    name = \"default\"\r\n    handlers = [\"default\", \"stderr\"]\r\n    level = \"warning\"\r\n\r\n[[main_app.general_settings.logging.loggers]]\r\n    name = \"http-access\"\r\n    handlers = [\"default\"]\r\n    level = \"info\"\r\n```\r\n\r\nNow here's the same configuration, expressed with arrays of extended tables. It offers clean, short lines for diff purposes.\r\n```toml\r\n# Example 2 with arrays of extended tables\r\n[main_app.general_settings.logging]\r\nlog-lib = \"logrus\"\r\n\r\nhandlers = [{\r\n    name = \"default\"\r\n    output = \"stdout\"\r\n    level = \"info\"\r\n}, {\r\n    name = \"stderr\"\r\n    output = \"stderr\"\r\n    level = \"error\"\r\n}, {\r\n    name = \"http-access\"\r\n    output = \"/var/log/access.log\"\r\n    level = \"info\"\r\n},]\r\n\r\nloggers = [{\r\n    name = \"default\"\r\n    handlers = [\"default\", \"stderr\"]\r\n    level = \"warning\"\r\n}, {\r\n    name = \"http-access\"\r\n    handlers = [\"default\"]\r\n    level = \"info\"\r\n},]\r\n```\r\n\r\nIssue #309 contains an array-of-inline-tables solution with long lines and rearranged keys. This example preserves the ordering of the keys. This proposal may also help us clear up concerns brought up over there."},"comment":{"url":"https://api.github.com/repos/toml-lang/toml/issues/comments/401987584","html_url":"https://github.com/toml-lang/toml/issues/525#issuecomment-401987584","issue_url":"https://api.github.com/repos/toml-lang/toml/issues/525","id":401987584,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMTk4NzU4NA==","user":{"login":"joshtriplett","id":162737,"node_id":"MDQ6VXNlcjE2MjczNw==","avatar_url":"https://avatars2.githubusercontent.com/u/162737?v=4","gravatar_id":"","url":"https://api.github.com/users/joshtriplett","html_url":"https://github.com/joshtriplett","followers_url":"https://api.github.com/users/joshtriplett/followers","following_url":"https://api.github.com/users/joshtriplett/following{/other_user}","gists_url":"https://api.github.com/users/joshtriplett/gists{/gist_id}","starred_url":"https://api.github.com/users/joshtriplett/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joshtriplett/subscriptions","organizations_url":"https://api.github.com/users/joshtriplett/orgs","repos_url":"https://api.github.com/users/joshtriplett/repos","events_url":"https://api.github.com/users/joshtriplett/events{/privacy}","received_events_url":"https://api.github.com/users/joshtriplett/received_events","type":"User","site_admin":false},"created_at":"2018-07-03T01:44:57Z","updated_at":"2018-07-03T01:44:57Z","author_association":"NONE","body":"I'd like to see this change as well. However, I would prefer to just treat these as inline tables, rather than making them a separate new element."}}
{"actor":{"display_login":"joshtriplett"}}