├── Accepted ├── 0003 - Generalized Tear-offs │ ├── LICENSE │ ├── README.md │ └── proposal.md ├── 0005 - Package Specification │ ├── .gitattributes │ ├── DEP-pkgspec.md │ └── packages_file │ │ ├── lib │ │ ├── loader.dart │ │ └── packages_file.dart │ │ ├── pubspec.yaml │ │ └── test │ │ ├── .packages-sample │ │ ├── test_all.dart │ │ └── test_loader.dart ├── 0009 - Null-aware Operators │ ├── LICENSE │ ├── README.md │ └── proposal.md ├── 0028 - Static Analysis on Function │ └── proposal.md └── 0034 - Less Restricted Mixins │ ├── LICENSE │ ├── README.md │ └── proposal.md ├── DEP Template.md ├── Flowchart.svg ├── Meetings ├── 2015-02-04 DEP Committee Meeting.md ├── 2015-02-18 DEP Committee Meeting.md ├── 2015-02-25 DEP Committee Meeting.md ├── 2015-03-04 DEP Committee Meeting.md ├── 2015-03-11 DEP Committee Meeting.md ├── 2015-03-18 DEP Committee Meeting.md ├── 2015-03-25 DEP Committee Meeting.md ├── 2015-05-06 DEP Committee Meeting.md ├── 2015-05-13 DEP Committee Meeting.md ├── 2015-05-20 DEP Committee Meeting.md ├── 2015-05-27 DEP Committee Meeting.md ├── 2015-06-03 DEP Committee Meeting.md ├── 2015-06-10 DEP Committee Meeting.md ├── 2015-06-24 DEP Committee Meeting.md ├── 2015-07-01 DEP Committee Meeting.md ├── 2015-08-12 DEP Committee Meeting.md ├── 2015-08-19 DEP Committee Meeting.md ├── 2015-08-26 DEP Committee Meeting.md ├── 2015-09-02 Language Meeting.md ├── 2015-09-09 Language Meeting.md ├── 2015-09-16 DEP Committee Meeting.md ├── 2015-09-30 DEP Committee Meeting.md ├── 2015-10-14 DEP Committee Meeting.md ├── 2015-10-21 DEP Committee Meeting.md ├── 2015-10-28 DEP Committee Meeting.md └── 2015-11-11 DEP Committee Meeting.md ├── README.md ├── Walkthrough.md └── codereview.settings /Accepted/0003 - Generalized Tear-offs/LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /Accepted/0003 - Generalized Tear-offs/README.md: -------------------------------------------------------------------------------- 1 | # generalizedTearOffs 2 | A proposal for supporting closurization for constructors, getters. setters and operators. 3 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/.gitattributes: -------------------------------------------------------------------------------- 1 | # Auto detect text files and perform LF normalization 2 | * text=auto 3 | 4 | # Custom for Visual Studio 5 | *.cs diff=csharp 6 | 7 | # Standard to msysgit 8 | *.doc diff=astextplain 9 | *.DOC diff=astextplain 10 | *.docx diff=astextplain 11 | *.DOCX diff=astextplain 12 | *.dot diff=astextplain 13 | *.DOT diff=astextplain 14 | *.pdf diff=astextplain 15 | *.PDF diff=astextplain 16 | *.rtf diff=astextplain 17 | *.RTF diff=astextplain 18 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/lib/loader.dart: -------------------------------------------------------------------------------- 1 | // Copyright (c) 2015, the Dart project authors. Please see the AUTHORS file 2 | // for details. All rights reserved. Use of this source code is governed by a 3 | // BSD-style license that can be found in the LICENSE file. 4 | 5 | /// Helper library for `packagecfg` that uses `dart:io` to save and load files. 6 | library packagemap.loader; 7 | 8 | import "packages_file.dart"; 9 | import "dart:io"; 10 | import "dart:async"; 11 | 12 | /// Loads a `.packages` file and parse the content into a [Packages] object. 13 | Future loadPackageConfig(File inputFile) { 14 | Uri fileUri = new Uri.file(inputFile.path); 15 | return inputFile.readAsString().then((String source) { 16 | return Packages.parse(source, fileUri); 17 | }); 18 | } 19 | 20 | /// Saves a [Packages] object to a `.packages` file. 21 | Future savePackageConfig(File outputFile, Packages packages) { 22 | // NOT TESTED. 23 | Uri fileUri = new Uri.file(outputFile.path); 24 | IOSink output = destination.openWrite(); 25 | packages.write(output, baseUri: fileUri); 26 | return packages.close(); 27 | } 28 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/lib/packages_file.dart: -------------------------------------------------------------------------------- 1 | // Copyright (c) 2015, the Dart project authors. Please see the AUTHORS file 2 | // for details. All rights reserved. Use of this source code is governed by a 3 | // BSD-style license that can be found in the LICENSE file. 4 | 5 | library packagemap; 6 | 7 | class Packages { 8 | static const int _EQUALS = 0x3d; 9 | static const int _CR = 0x0d; 10 | static const int _NL = 0x0a; 11 | static const int _NUMBER_SIGN = 0x23; 12 | 13 | final Map packageMapping; 14 | 15 | Packages(this.packageMapping); 16 | 17 | /// Resolves a URI to a non-package URI. 18 | /// 19 | /// If [uri] is a `package:` URI, the location is resolved wrt. the 20 | /// [packageMapping]. 21 | /// Otherwise the original URI is returned. 22 | Uri resolve(Uri uri) { 23 | if (uri.scheme.toLowerCase() != "package") { 24 | return uri; 25 | } 26 | if (uri.hasAuthority) { 27 | throw new ArgumentError.value(uri, "uri", "Must not have authority"); 28 | } 29 | if (uri.path.startsWith("/")) { 30 | throw new ArgumentError.value(uri, "uri", 31 | "Path must not start with '/'."); 32 | } 33 | // Normalizes the path by removing '.' and '..' segments. 34 | uri = uri.normalizePath(); 35 | String path = uri.path; 36 | var slashIndex = path.indexOf('/'); 37 | String packageName; 38 | String rest; 39 | if (slashIndex < 0) { 40 | packageName = path; 41 | rest = ""; 42 | } else { 43 | packageName = path.substring(0, slashIndex); 44 | rest = path.substring(slashIndex + 1); 45 | } 46 | Uri packageLocation = packageMapping[packageName]; 47 | if (packageLocation == null) { 48 | throw new ArgumentError.value(uri, "uri", 49 | "Unknown package name: $packageName"); 50 | } 51 | return packageLocation.resolveUri(new Uri(path: rest)); 52 | } 53 | 54 | /// Parses a `.packages` file into a `Packages` object. 55 | /// 56 | /// The [baseLocation] is used as a base URI to resolve all relative 57 | /// URI references against. 58 | /// 59 | /// The `Packages` object allows resolving package: URIs and writing 60 | /// the mapping back to a file or string. 61 | /// The [packageMapping] will contain a simple mapping from package name 62 | /// to package location. 63 | static Packages parse(String source, Uri baseLocation) { 64 | int index = 0; 65 | Map result = {}; 66 | while (index < source.length) { 67 | bool isComment = false; 68 | int start = index; 69 | int eqIndex = -1; 70 | int end = source.length; 71 | int char = source.codeUnitAt(index++); 72 | if (char == _CR || char == _NL) { 73 | continue; 74 | } 75 | if (char == _EQUALS) { 76 | throw new FormatException("Missing package name", source, index - 1); 77 | } 78 | isComment = char == _NUMBER_SIGN; 79 | while (index < source.length) { 80 | char = source.codeUnitAt(index++); 81 | if (char == _EQUALS && eqIndex < 0) { 82 | eqIndex = index - 1; 83 | } else if (char == _NL || char == _CR) { 84 | end = index - 1; 85 | break; 86 | } 87 | } 88 | if (isComment) continue; 89 | if (eqIndex < 0) { 90 | throw new FormatException("No '=' on line", source, index - 1); 91 | } 92 | _checkIdentifier(source, start, eqIndex); 93 | var packageName = source.substring(start, eqIndex); 94 | 95 | var packageLocation = Uri.parse(source, eqIndex + 1, end); 96 | if (!packageLocation.path.endsWith('/')) { 97 | packageLocation = packageLocation.replace( 98 | path: packageLocation.path + "/"); 99 | } 100 | packageLocation = baseLocation.resolveUri(packageLocation); 101 | if (result.containsKey(packageName)) { 102 | throw new FormatException("Same package name occured twice.", 103 | source, start); 104 | } 105 | result[packageName] = packageLocation; 106 | } 107 | return new Packages(result); 108 | } 109 | 110 | /** 111 | * Writes the mapping to a [StringSink]. 112 | * 113 | * If [comment] is provided, the output will contain this comment 114 | * with `#` in front of each line. 115 | * 116 | * If [baseUri] is provided, package locations will be made relative 117 | * to the base URI, if possible, before writing. 118 | */ 119 | void write(StringSink output, {Uri baseUri, String comment}) { 120 | if (baseUri != null && !baseUri.isAbsolute) { 121 | throw new ArgumentError.value(baseUri, "baseUri", "Must be absolute"); 122 | } 123 | 124 | if (comment != null) { 125 | for (var commentLine in comment.split('\n')) { 126 | output.write('#'); 127 | output.writeln(commentLine); 128 | } 129 | } else { 130 | output.write("# generated by package:packagecfg at "); 131 | output.write(new DateTime.now()); 132 | output.writeln(); 133 | } 134 | 135 | packageMapping.forEach((String packageName, Uri uri) { 136 | // Validate packageName. 137 | _checkIdentifier(packageName, 0, packageName.length); 138 | output.write(packageName); 139 | 140 | output.write('='); 141 | 142 | // If baseUri provided, make uri relative. 143 | if (baseUri != null) { 144 | uri = _relativizeUri(uri, baseUri); 145 | } 146 | output.write(uri); 147 | if (!uri.path.endsWith('/')) { 148 | output.write('/'); 149 | } 150 | output.writeln(); 151 | }); 152 | } 153 | 154 | String toString() { 155 | StringBuffer buffer = new StringBuffer(); 156 | write(buffer); 157 | return buffer.toString(); 158 | } 159 | 160 | static Uri relativize(Uri uri, 161 | Uri baseUri) { 162 | if (uri.hasQuery || uri.hasFragment) { 163 | uri = new Uri(scheme: uri.scheme, 164 | userInfo: uri.hasAuthority ? uri.userInfo : null, 165 | host: uri.hasAuthority ? uri.host : null, 166 | port: uri.hasAuthority ? uri.port : null, 167 | path: uri.path); 168 | } 169 | if (!baseUri.isAbsolute) { 170 | throw new ArgumentError("Base uri '$baseUri' must be absolute."); 171 | } 172 | // Already relative. 173 | if (!uri.isAbsolute) return uri; 174 | 175 | if (baseUri.scheme.toLowerCase() != uri.scheme.toLowerCase()) { 176 | return uri; 177 | } 178 | // If authority differs, we could remove the scheme, but it's not worth it. 179 | if (uri.hasAuthority != baseUri.hasAuthority) return uri; 180 | if (uri.hasAuthority) { 181 | if (uri.userInfo != baseUri.userInfo || 182 | uri.host.toLowerCase() != baseUri.host.toLowerCase() || 183 | uri.port != baseUri.port) { 184 | return uri; 185 | } 186 | } 187 | 188 | List base = baseUri.pathSegments.toList(); 189 | base = base.normalizePath(); 190 | if (base.isNotEmpty) { 191 | base = new List.from(base)..removeLast(); 192 | } 193 | List target = uri.pathSegments.toList(); 194 | target = target.normalizePath(); 195 | int index = 0; 196 | while (index < base.length && index < target.length) { 197 | if (base[index] != target[index]) { 198 | break; 199 | } 200 | index++; 201 | } 202 | if (index == base.length) { 203 | return new Uri(path: target.skip(index).join('/')); 204 | } else if (index > 0) { 205 | return new Uri( 206 | path: '../' * (base.length - index) + target.skip(index).join('/')); 207 | } else { 208 | return uri; 209 | } 210 | } 211 | 212 | static void _checkIdentifier(String string, int start, int end) { 213 | const int a = 0x61; 214 | const int z = 0x7a; 215 | const int _ = 0x5f; 216 | const int $ = 0x24; 217 | if (start == end) return false; 218 | for (int i = start; i < end; i++) { 219 | var char = string.codeUnitAt(i); 220 | if (char == _ || char == $) continue; 221 | if ((char ^ 0x30) <= 9 && i > 0) continue; 222 | char |= 0x20; // Lower-case letters. 223 | if (char >= a && char <= z) continue; 224 | throw new FormatException("Not an identifier", string, i); 225 | } 226 | } 227 | } 228 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/pubspec.yaml: -------------------------------------------------------------------------------- 1 | name: packages_file 2 | version: 0.1.0 3 | author: Dart Team 4 | description: Read and write packages.map files. 5 | homepage: http://www.dartlang.org 6 | dev_dependencies: 7 | unittest: ">=0.10.0 <0.12.0" 8 | environment: 9 | sdk: ">=1.11.0-edge <2.0.0" 10 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/test/.packages-sample: -------------------------------------------------------------------------------- 1 | # Sample file, do not edit. 2 | foo=../lib/ 3 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/test/test_all.dart: -------------------------------------------------------------------------------- 1 | // Copyright (c) 2015, the Dart project authors. Please see the AUTHORS file 2 | // for details. All rights reserved. Use of this source code is governed by a 3 | // BSD-style license that can be found in the LICENSE file. 4 | 5 | library test_all; 6 | 7 | import "package:unittest/unittest.dart"; 8 | import "package:packages_file/packags_file.dart"; 9 | 10 | main() { 11 | var base = Uri.parse("file:///one/two/three/.packages"); 12 | test("empty", () { 13 | var packages = Packages.parse(emptySample, base); 14 | expect(packages.packageMapping, isEmpty); 15 | }); 16 | test("comment only", () { 17 | var packages = Packages.parse(commentOnlySample, base); 18 | expect(packages.packageMapping, isEmpty); 19 | }); 20 | test("empty lines only", () { 21 | var packages = Packages.parse(emptyLinesSample, base); 22 | expect(packages.packageMapping, isEmpty); 23 | }); 24 | 25 | test("empty lines only", () { 26 | var packages = Packages.parse(emptyLinesSample, base); 27 | expect(packages.packageMapping, isEmpty); 28 | }); 29 | 30 | test("single", () { 31 | var packages = Packages.parse(singleRelativeSample, base); 32 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 33 | expect(packages.resolve(Uri.parse("package:foo/bar/baz.dart")), 34 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 35 | }); 36 | 37 | test("single no slash", () { 38 | var packages = Packages.parse(singleRelativeSampleNoSlash, base); 39 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 40 | expect(packages.resolve(Uri.parse("package:foo/bar/baz.dart")), 41 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 42 | }); 43 | 44 | test("single no newline", () { 45 | var packages = Packages.parse(singleRelativeSampleNoNewline, base); 46 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 47 | expect(packages.resolve(Uri.parse("package:foo/bar/baz.dart")), 48 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 49 | }); 50 | 51 | test("single absolute", () { 52 | var packages = Packages.parse(singleAbsoluteSample, base); 53 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 54 | expect(packages.resolve(Uri.parse("package:foo/bar/baz.dart")), 55 | equals(Uri.parse("http://example.com/some/where/bar/baz.dart"))); 56 | }); 57 | 58 | test("multiple", () { 59 | var packages = Packages.parse(multiRelativeSample, base); 60 | expect(packages.packageMapping.keys.toList()..sort(), 61 | equals(["bar", "foo"])); 62 | expect(packages.resolve(Uri.parse("package:foo/bar/baz.dart")), 63 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 64 | expect(packages.resolve(Uri.parse("package:bar/foo/baz.dart")), 65 | equals(base.resolve("../test2/").resolve("foo/baz.dart"))); 66 | }); 67 | 68 | test("dot-dot 1", () { 69 | var packages = Packages.parse(singleRelativeSample, base); 70 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 71 | expect(packages.resolve(Uri.parse("package:foo/qux/../bar/baz.dart")), 72 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 73 | }); 74 | 75 | test("dot-dot 2", () { 76 | var packages = Packages.parse(singleRelativeSample, base); 77 | expect(packages.packageMapping.keys.toList(), equals(["foo"])); 78 | expect(packages.resolve(Uri.parse("package:qux/../foo/bar/baz.dart")), 79 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 80 | }); 81 | 82 | test("all valid chars", () { 83 | var packages = Packages.parse(allValidCharsSample, base); 84 | expect(packages.packageMapping.keys.toList(), equals([allValidChars])); 85 | expect(packages.resolve(Uri.parse("package:$allValidChars/bar/baz.dart")), 86 | equals(base.resolve("../test/").resolve("bar/baz.dart"))); 87 | }); 88 | 89 | test("no escapes", () { 90 | expect(() => Packages.parse("x%41x=x", base), throws); 91 | }); 92 | 93 | test("not identifiers", () { 94 | expect(() => Packages.parse("1x=x", base), throws); 95 | expect(() => Packages.parse(" x=x", base), throws); 96 | expect(() => Packages.parse("\\x41x=x", base), throws); 97 | expect(() => Packages.parse("x@x=x", base), throws); 98 | expect(() => Packages.parse("x[x=x", base), throws); 99 | expect(() => Packages.parse("x`x=x", base), throws); 100 | expect(() => Packages.parse("x{x=x", base), throws); 101 | expect(() => Packages.parse("x/x=x", base), throws); 102 | expect(() => Packages.parse("x:x=x", base), throws); 103 | }); 104 | 105 | test("same name twice", () { 106 | expect(() => Packages.parse(singleRelativeSample * 2, base), 107 | throws); 108 | }); 109 | 110 | for (String invalidSample in invalid) { 111 | test("invalid '$invalidSample'", () { 112 | var result; 113 | try { 114 | result = Packages.parse(invalidSample, base); 115 | } on FormatException { 116 | // expected 117 | return; 118 | } 119 | fail("Resolved to $result"); 120 | }); 121 | } 122 | } 123 | 124 | // Valid samples. 125 | var emptySample = ""; 126 | var commentOnlySample = "# comment only\n"; 127 | var emptyLinesSample = "\n\n\r\n"; 128 | var singleRelativeSample = "foo=../test/\n"; 129 | var singleRelativeSampleNoSlash = "foo=../test\n"; 130 | var singleRelativeSampleNoNewline = "foo=../test/"; 131 | var singleAbsoluteSample = "foo=http://example.com/some/where/\n"; 132 | var multiRelativeSample = "foo=../test/\nbar=../test2/\n"; 133 | // All valid path segment characters in an URI. 134 | var allValidChars = 135 | r"$0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"; 136 | var allValidCharsSample = "${allValidChars.replaceAll('=', '%3D')}=../test/\n"; 137 | var allUnreservedChars = 138 | "-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~"; 139 | 140 | // Invalid samples. 141 | var invalid = [ 142 | "foobar:baz.dart", // no equals 143 | ".=../test/", // dot segment 144 | "..=../test/", // dot-dot segment 145 | "foo/bar=../test/", // 146 | "/foo=../test/", // var multiSegmentSample 147 | "?=../test/", // invalid characters in path segment. 148 | "[=../test/", // invalid characters in path segment. 149 | "x#=../test/", // invalid characters in path segment. 150 | ]; 151 | -------------------------------------------------------------------------------- /Accepted/0005 - Package Specification/packages_file/test/test_loader.dart: -------------------------------------------------------------------------------- 1 | // Copyright (c) 2015, the Dart project authors. Please see the AUTHORS file 2 | // for details. All rights reserved. Use of this source code is governed by a 3 | // BSD-style license that can be found in the LICENSE file. 4 | 5 | library test_loader; 6 | 7 | import "dart:io"; 8 | import "package:unittest/unittest.dart"; 9 | import "package:packages_file/packages_file.dart"; 10 | import "package:packages_file/loader.dart"; 11 | 12 | main() { 13 | test("load", () { 14 | // Test works if run from text/ directory or package root directory. 15 | var file = new File(".packages-sample"); 16 | if (!file.existsSync()) { 17 | file = new File("test/.packages-sample"); 18 | } 19 | return loadPackageConfig(file.absolute) 20 | .then((Packages packages) { 21 | Uri resolved = packages.resolve(Uri.parse("package:foo/bar/baz.dart")); 22 | expect(resolved.path.endsWith("/lib/bar/baz.dart"), isTrue); 23 | }); 24 | }); 25 | } 26 | -------------------------------------------------------------------------------- /Accepted/0009 - Null-aware Operators/LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | 203 | -------------------------------------------------------------------------------- /Accepted/0009 - Null-aware Operators/README.md: -------------------------------------------------------------------------------- 1 | # nullAwareOperators 2 | Proposal for null-aware operators in Dart 3 | -------------------------------------------------------------------------------- /Accepted/0009 - Null-aware Operators/proposal.md: -------------------------------------------------------------------------------- 1 | #Null-aware Operators 2 | 3 | ## Contact information 4 | 5 | 1. **Gilad Bracha.** 6 | 7 | 2. **gbracha@google.com.** 8 | 9 | 3. **https://github.com/gbracha/nullAwareOperators** 10 | 11 | 12 | 13 | ##Summary 14 | 15 | 16 | We propose the addition of the following operators: 17 | 18 | * `?.` where *a?.b* is sugar for `a == ` **null** `? ` **null** ` : a.b`. 19 | 20 | * The null-coalescing operator (aka ifNull) `??` where *a??b* is sugar for `a == ` **null**` ? b : a`. 21 | 22 | * `??=` where *v ??= e* is sugar for `v = v ?? ` *e*. 23 | 24 | ##Motivation 25 | 26 | See bugs: 27 | 28 | * https://code.google.com/p/dart/issues/detail?id=41 29 | * https://code.google.com/p/dart/issues/detail?id=1236 30 | 31 | 32 | 33 | ###Pros 34 | 35 | * Simple. Effects are entirely local, specified by translation to existing Dart. 36 | 37 | ###Cons 38 | 39 | * Syntactic sugar causes cancer of the semicolon. 40 | 41 | * There might be demand for extensions. For example, compound null-aware assignment, e.g., `a?+= x`. These are not supported. The fact that they are not supported is not, in my view, a weakness of the proposal. The weakness is that it gives rise to such temptations. 42 | 43 | * Allows for 'elvis closurization' as in `a?.m` where *m* is a method, not because this is desired, but because it is not easily distinguished from other cases. In some sense this runs counter to the desire to clean up closurization as described in the [generalized tear offs proposal](https://github.com/gbracha/generalizedTearOffs). I'd rather not introduce things like `a?#m`. 44 | 45 | * Does not support operators. 46 | 47 | 48 | ##Examples 49 | 50 | ``` 51 | if ((stringMightBeNull ?? "").length == 0) { 52 | // string is empty or null 53 | } 54 | ``` 55 | 56 | `zip = lottery?.drawWinner()?.address?.zipcode` 57 | 58 | 59 | ## Proposal 60 | 61 | See above. The proposal is strictly limited to the above syntactic transforms. 62 | 63 | 64 | 65 | 66 | ## Deliverables 67 | 68 | 69 | ### Language specification changes 70 | 71 | 72 | 73 | 74 | #### 16.19.1 Compound Assignment 75 | 76 | A compound assignment of the form *v op= e* is equivalent to *v=v op e*. A compound assignment of the form *C.v op= e* is equivalent to *C.v = C.v op e*. A compound assignment of the form *e1.v op = e2* is equivalent to `((x) => x.v = x.v op e2)(e1)` where *x* is a variable that is not used in *e2*. A compound assignment of the form *e1[e2] op= e3* is equivalent to `((a, i) => a[i] = a[i] op e3)(e1, e2)` where *a* and *i* are variables that are not used in *e3*. 77 | ; 78 | 79 | 80 | ``` 81 | compoundAssignmentOperator: 82 | 83 | ‘*=’ | 84 | ‘/=’ | 85 | ‘ ̃/=’ | 86 | ‘%=’ | 87 | ‘+=’ | 88 | ‘-=’ | 89 | ‘<<=’ | 90 | ‘>>=’ | 91 | ‘&=’ | 92 | ‘ˆ=’ | 93 | ‘|=’ 94 | ‘??=’ 95 | ; 96 | ``` 97 | 98 | **?? can either replace unaryExpression or logicalOrExpression. Assuming the latter.** 99 | 100 | #### 16.20 Conditional 101 | 102 | A conditional expression evaluates one of two expressions based on a boolean condition. 103 | conditionalExpression: 104 | 105 | ``` 106 | ifNullExpression (‘ ?’ expressionWithoutCascade ‘:’ expressionWithoutCascade)? 107 | ; 108 | ``` 109 | **Rest of section 16.20 is unchanged** 110 | 111 | 112 | #### 16.xx If-**null** Expression 113 | 114 | An *if-null* expression evaluates an expression and if the result is **null**, evaluates another. 115 | 116 | ``` 117 | ifNullExpression: 118 | logicalOrExpression ‘??’ logicalOrExpression 119 | ``` 120 | 121 | An if-null expression of the form *e1??e2* is equivalent to the expression *e1 == null? e2: e1*. 122 | 123 | #### 16.31 Assignable Expressions 124 | 125 | Assignable expressions are expressions that can appear on the left hand side of an assignment. This section describes how to evaluate these expressions when they do not constitute the complete left hand side of an assignment. 126 | 127 | *Of course, if assignable expressions always appeared as the left hand side, one would have no need for their value, and the rules for evaluating them would be unnecessary. However, assignable expressions can be subexpressions of other expressions and therefore must be evaluated.* 128 | 129 | ``` 130 | assignableExpression: 131 | primary (arguments* assignableSelector)+ | 132 | super assignableSelector | 133 | identifier 134 | ; 135 | 136 | assignableSelector: 137 | ‘[’ expression ‘]’ | 138 | ‘.’ identifier | 139 | ‘?.’ identifier 140 | ; 141 | ``` 142 | An assignable expression can be conditional or unconditional. 143 | 144 | A conditional assignable expression of the form *e1?.identifier* is equivalent to the expression 145 | `e1 == ` **null** `? ` **null** ` : e1.identifier`. 146 | 147 | An unconditional assignable expression is either: 148 | 149 | **Rest of section 16.31 is unchanged** 150 | 151 | ### A working implementation 152 | 153 | TBD 154 | 155 | ### Tests 156 | 157 | TBD 158 | 159 | ## Patents rights 160 | 161 | [tex]: http://www.latex-project.org/ 162 | [language spec]: https://www.dartlang.org/docs/spec/ 163 | [dart standard]: http://www.ecma-international.org/publications/standards/Ecma-408.htm 164 | [rfpp]: http://www.ecma-international.org/memento/TC52%20policy/Ecma%20Experimental%20TC52%20Royalty-Free%20Patent%20Policy.pdf 165 | [external contributer form]: http://www.ecma-international.org/memento/TC52%20policy/Contribution%20form%20to%20TC52%20Royalty%20Free%20Task%20Group%20as%20a%20non-member.pdf 166 | -------------------------------------------------------------------------------- /Accepted/0028 - Static Analysis on Function/proposal.md: -------------------------------------------------------------------------------- 1 | #Let static analysis allow any call on `Function` type. 2 | 3 | ## Contact information 4 | 5 | Name: Lasse R.H. Nielsen 6 | E-mail: lrn@google.com 7 | [DEP Proposal Location][] 8 | 9 | ## Summary 10 | 11 | The current specification does not consider the type `Function` to be callable. 12 | Example: 13 | ```dart 14 | void foo(Function bar) { return bar(); } 15 | ``` 16 | This example should give a warning at the call point `bar()` because the static type of `bar` does not have a method called `call`. 17 | 18 | This proposal proposes to remove the requirement for a warning when calling something with the static type `Function`, effectively assuming that it has *some* member named 19 | `call`. 20 | 21 | ## Background and motivation 22 | The [Dart standard][] currently requires warning for code that calls expression with static type `Function`, where `Function` is the type in `dart:core`. 23 | 24 | Implementations of Dart have not produced this warning ([Analyzer Issue]), and existing code has assumed that code as the one above is perfectly fine. 25 | 26 | In practice, the Dart type system makes it somewhat cumbersome to specify a function type for fields or return types, and code has been written using `Function` indended just as a sligtly more precise alternative to `dynamic`. This includes code in the Dart platform libraries. 27 | 28 | Changing the analyzer behavior is problematic because it will cause existing code to give new warnings. That's not an argument against fixing the behavior, but it shows the scale of the mis-use. If a significant number of programmers is using a bug as a feature, it suggest that there is a need for that feature. Changing the specification to match the implementations would give the user the feature that they are already using, only with a full specification behind it. 29 | 30 | ## Proposal 31 | The [Dart standard][] section 16.7.1 (Ordinary invocation) has a paragraph listing exceptions where a warning is not needed, prefixed by: 32 | > Let /T/ be the static type of /o/. It is a static type warning if /T/ does not have an accessible (6.2) instance member named /m/ unless either:` 33 | To this list, a third item should be added: 34 | > * /T/ is **Function** and /m/ is **call**. 35 | 36 | Similarly, section 16.18.7 (Property Extraction) has a similar list that should also have the same third item added. This allows reading `o.call` from an object `o` with static type `Function` without getting a warning. 37 | 38 | The result of the property extraction will have type `dynamic`. 39 | If possible, it might also be worth it to special case the static type of the property extraction of `call` on somthing typed `Function` to be `Function`. It's not necessary to cover the current uses 40 | 41 | ## Implications 42 | The proposed change disables some type-checking that the current specification requires. 43 | No current implementation has actually implemented the specification, and the change would make the current implementations be correct. As such, no user code should be affected. 44 | 45 | The required warnings would detect code that 46 | * has typed a function value as `Function`, and 47 | * is calling the function or reading its `call` method. 48 | Such code tends to be deliberate since the alternative to specifying `Function` is to default to `dynamic`. As such, enforcing the warnings would likely just turn the type annotation back to `dynamic` for such code, catching even fewer actual errors instead of catching more. 49 | 50 | ## Deliverables 51 | 52 | ### Language specification changes 53 | 54 | The changes to the specification are simple and described above.. 55 | 56 | ### A working implementation 57 | 58 | No implementation need to change to support the changed specification, since they are already implementing the proposed static semantics. 59 | 60 | Pure runtime implementations like the VM are unaffected by the change. 61 | 62 | ## Patents rights 63 | 64 | TC52, the Ecma technical committee working on evolving the open [Dart standard][], operates under a royalty-free patent policy, [RFPP][] (PDF). This means if the proposal graduates to being sent to TC52, you will have to sign the Ecma TC52 [external contributer form]() and submit it to Ecma. 65 | 66 | [Analyzer Issue]: http://dartbug.com/21938 67 | [DEP Proposal Location]: https://github.com/lrhn/dep-functiontype/ 68 | [Dart standard]: http://www.ecma-international.org/publications/standards/Ecma-408.htm 69 | [rfpp]: http://www.ecma-international.org/memento/TC52%20policy/Ecma%20Experimental%20TC52%20Royalty-Free%20Patent%20Policy.pdf 70 | [form]: http://www.ecma-international.org/memento/TC52%20policy/Contribution%20form%20to%20TC52%20Royalty%20Free%20Task%20Group%20as%20a%20non-member.pdf 71 | -------------------------------------------------------------------------------- /Accepted/0034 - Less Restricted Mixins/README.md: -------------------------------------------------------------------------------- 1 | # lessRestrictedMixins 2 | Lift some, but not all, of the current restrictions on mixins in Dart. 3 | -------------------------------------------------------------------------------- /DEP Template.md: -------------------------------------------------------------------------------- 1 | # Proposal name 2 | 3 | The name of your proposal. Make it brief but unambiguous. We will be referring to it in hallway conversations, email, comment threads, and likely in our dreams, so make it snappy but try to spare the buzzwords and marketing. 4 | 5 | ## Contact information 6 | 7 | Three key pieces of information are required: 8 | 9 | 1. **Your name.** As the author, you are signing up to shepherd this proposal through the process. (A proposal *can* be passed on to someone else if really needed, but at any point in time, it must have a living breathing owner who actively cares about it.) 10 | 11 | 2. **Your contact information.** Email address at a bare minimum. A GitHub account is good too. 12 | 13 | 3. **The repository where this proposal and its associated artifacts lives.** At first, this document will live *in* that repo, so it's kind of implicit. But, when the proposal is approved, the text will be migrated into the canonical repository for completed DEPs. At that point, we want it to point out to the original repo so readers can find the other artifacts, history, and discussion. 14 | 15 | In addition, a list of other stakeholders is good. These are people who have a vested interest and relevant expertise in the proposal. Good stakeholders are ones who: 16 | 17 | - Own important Dart applications or frameworks. 18 | - Are acutely feeling the pain this proposal addresses. 19 | - Can provide clear, articulate feedback. 20 | 21 | Names, email, and GitHub accounts if they have them. 22 | 23 | ## Summary 24 | 25 | A brief description of the proposal. Think a couple of sentences or 26 | a short paragraph. Maybe a small snippet of code or example. 27 | 28 | ## Motivation 29 | 30 | This is in many ways the most important section. It motivates the reader to care about the problems or shortcomings this proposal addresses. The language specification and the language committee are both finite resources. Tell us why we should spend them on this issue instead of others. 31 | 32 | Describe in detail the existing problems or use cases this proposal addresses. A use case is more compelling when: 33 | 34 | - It affects a large number of users. 35 | - These users are writing real-world programs. 36 | - It's difficult or impossible to workaround the problems. 37 | 38 | In other words, the ideal motivation is a problem that's preventing every Dart user from shipping their app. 39 | 40 | ## Examples 41 | 42 | Now that you've hopefully sold us caring about the problem, show us your solution. We'll get into the general behavior soon, but first, walk us through a few realistic examples of how the proposal would be used in practice. 43 | 44 | Humans tend to absorb information better if you start with examples and then show the general principle, so this is the place for your proposal's highlight reel. It gives us readers a chance to develop and intuition for what your proposal does and get a feel for its user experience. 45 | 46 | Try to use real-world examples. Keep them small, but with realistic context. "Foo" and "bar" make it hard to evaluate how the proposal would look in real code. 47 | 48 | ## Proposal 49 | 50 | At this point, we should care about your problem and think your solution looks beautiful. Now it's time to dig in and explain how it works in detail. Cover the syntax and semantics precisely and clearly. 51 | 52 | Describe its behavior in common usage, but also how it acts in bizarre corner cases. You don't need to be as precise as actual language spec verbiage, but this is the place where you start heading in that direction. 53 | 54 | This is probably the least fun, but ultimately the most important section. 55 | 56 | ## Alternatives 57 | 58 | While you may think of your solution as a perfect snowflake, there are other pretty snowflakes out there. Describe alternate solutions that cover the same space as this proposal. Compare them to the proposal and each other and explain why they were rejected. 59 | 60 | What advantages do these alternatives have that the chosen one lacks? What does the selected proposal offer to outweigh them? Being rigorous here shows that you've done your due diligence and fully explored both the problem and the potential solution space. We want to be confident that we have not just *a* solution to the problem, but the *best* one. 61 | 62 | ## Implications and limitations 63 | 64 | A good language is a cohesive whole. Even a small, well-defined proposal still has to hang together with the rest of the Dart platform. 65 | 66 | - How does this feature interact with the other language features—in both good and bad ways—? 67 | - If we adopt this feature what will it prevent us from doing now? What do we sacrifice for this? 68 | - How does it affect the future evolution of the language? 69 | 70 | ## Deliverables 71 | 72 | These don't have to be done *initially* but before the proposal can be given the final stamp of approval before it's shipped off to TC 52, three key artifacts are required. 73 | 74 | These will live in the same repo as your proposal. 75 | 76 | ### Language specification changes 77 | 78 | These the actual, precise diffs for how the [language spec][] will be modified. 79 | Time to brush up on your [TeX][]. Being able to do this well is a rare gift, so 80 | you are not expected to be a spec wizard. Fortunately, we have a couple on 81 | staff. Do your best and as your proposal matures, we will help. 82 | 83 | ### A working implementation 84 | 85 | Nothing flushes out the problems with a feature quite like writing it in cold, hard executable code. Before a proposal can be approved, some kind of working implementation must be provided. 86 | 87 | Again, you don't have to have this on day one. However, you should make as much progress on this as early as you can. You *are* expected to be able to write working code, so there's nothing really holding you back. Doing this before you show your proposal to the world is a good sanity check to ensure you don't propose something that turns out to be impossible to implement. (It happens to the best of us.) 88 | 89 | It's not necessary to actually implement your feature in the native Dart VM or dart2js compiler (though you can and will certainly get street cred for doing so). Instead, you may: 90 | 91 | * Write some sort of standalone prototype implementation. 92 | * Write a [transpiler][] that takes Dart code using your feature and translates it to "vanilla" Dart code. 93 | 94 | [transpiler]: https://en.wikipedia.org/wiki/Source-to-source_compiler 95 | 96 | What matters is that you demonstrate that the feature can feasibly be implemented in a reasonable amount of code with good performance. 97 | 98 | ### Tests 99 | 100 | Write tests that could be run under an implementation to determine if it implements your proposal correctly. Make sure to test both success and failure cases. Be thorough. Programming languages have combinatorial input, so defining a comprehensive test suite is difficult. 101 | 102 | Imagine an adversary is going to write a malicious implementation of your proposal that passes its tests but otherwise does things so horrible it will cause the language team to run screaming from your proposal. Don't let the adversary win. 103 | 104 | [tex]: http://www.latex-project.org/ 105 | [language spec]: https://www.dartlang.org/docs/spec/ 106 | [dart standard]: http://www.ecma-international.org/publications/standards/Ecma-408.htm 107 | [external contributer form]: http://www.ecma-international.org/memento/TC52%20policy/Contribution%20form%20to%20TC52%20Royalty%20Free%20Task%20Group%20as%20a%20non-member.pdf 108 | -------------------------------------------------------------------------------- /Meetings/2015-02-04 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Anders][], [Bob][], [Erik][], [Gilad][], [Lars][], [Lasse][]. 2 | 3 | [anders]: https://github.com/anders-sandholm 4 | [bob]: https://github.com/munificent 5 | [erik]: https://github.com/ErikErnst 6 | [gilad]: https://github.com/gbracha 7 | [lars]: https://github.com/larsbak 8 | [lasse]: https://github.com/lrhn 9 | 10 | ## When should the committee meet? 11 | 12 | This is surprisingly tricky because half of the committee is in Denmark and the other half is on the West Coast of the US. In addition, some of our more illustrious committee members tend to have pretty full schedules. After some deliberation and calendar-poking we arrived at: 13 | 14 | * Every Wednesday from 11:00am–12:00pm, Pacific Time 15 | 16 | Through a miracle of timing, now is actually a good time to find open conference rooms in the ever-crowded Mountain View campus so Gilad will be staking out his territory forthwith. 17 | 18 | ## What is the scope of the committee? 19 | 20 | Three categories of improvement: 21 | 22 | * Language 23 | * Core libraries 24 | * The broader "SDK" 25 | 26 | By the last, we mean tools and other core parts of the Dart platform. We'll treat all three of these as under the holistic umbrella of the DEP committee. 27 | 28 | ## What issues will we be going over first? 29 | 30 | Gilad has two proposals that are pretty mature: 31 | 32 | * One on broadening what kind of tear-offs are supported. Right now, Dart 33 | only lets you tear off methods, like so: 34 | 35 | ```dart 36 | var tearOff = "some string".toString; 37 | // tearOff is now a closure that invokes toString() on 38 | // "some string" when called. 39 | print(tearOff()); // "some string" 40 | ``` 41 | 42 | This would extend that to support tearing off constructors and possibly 43 | other members. 44 | 45 | * Another proposal for making runtime `Type` objects more capable. 46 | 47 | While these have already been written up, we'll use them as canaries to run through the proposed DEP workflow so we can get a sense for how all of the mechanics work in practice. 48 | 49 | Doing this is more work, but it will let us iterate on the process itself before we open it up to other contributors. 50 | 51 | Anders: "Markdown FTW! Who needs LaTex?" 52 | 53 | ## Documenting the DEP process 54 | 55 | We went through some less-than-thrilling administrivia about who can review 56 | documentation commits to the dart_enhancement_proposals repo itself. 57 | 58 | For substantive patches that change our official workflow, we need someone on 59 | the committee itself like Anders to approve it. For filling in docs on things 60 | that have already been decided, any PM on the team can give the LGTM. 61 | 62 | ## When are we going to open the process up to the public? 63 | 64 | Before we can go live, we want to get some feedback and iterate on the documentation in the repo and make sure that's all in good shape and we're happy with it. 65 | 66 | We also want to have a couple of DEPs already in the pipeline. That will let people see how the process works. For those who want to write their own proposals, it will give them concrete examples to learn from and get a sense of what a good DEP looks like. 67 | 68 | Most of the DEP committee will be in Mountain View later this month for the TC 52 meeting anyway, so we'll aim to launch it after that. We're looking at **Feb 26th** to make the repo public and announce it on the site. 69 | 70 | By then, the docs should be solid, and we should have two DEPs that we'd have some time to crank on in a couple of meetings. 71 | 72 | The tear-off proposal is already in pretty good shape, so that should be straightforward. The other proposal might make sense to be rolled into that one, or maybe it should be a separate one that starts off a little barebones. We'll just see how the first goes and take it from there. 73 | 74 | ## Meeting notes 75 | 76 | More administrivia about take meeting notes. I'll spare you the details so you don't fall asleep reading them. 77 | 78 | ## Summary 79 | 80 | We're really excited to get this process up and running. People will get to see what changes are happening and what they're status is. They'll be able to participate, and everything will be more transparent. 81 | 82 | ## DEP repos 83 | 84 | We talked about the proposed workflow where each DEP lives in its own repo. In our repo, we'll maintain an open tracking issue for each DEP. That issue uniquely identifies the proposal. The label on the issue defines the status of that proposal. 85 | 86 | This means you can do a simple query on the dart_enhancement_proposals issue tracker to see what the status of every DEP is. 87 | 88 | We'll give this workflow a try and see how it goes. 89 | 90 | ## [TLA][] 91 | 92 | There was some discussion about changing this from "DIP" to "DEP". We originally called these "Dart *Improvement* Proposals". But "improvement" might carry a connotation that the current Dart isn't quite so good. More importantly, "dip" has negative connotations in the US meaning a somewhat-intellectually-challenged person. 93 | 94 | Thus: Dart *Enhancement* Proposals. "DEP" can also be used to mean "dependency", but we think it will be clear which one is being referred to in context. 95 | 96 | [tla]: http://en.wikipedia.org/wiki/Three-letter_acronym -------------------------------------------------------------------------------- /Meetings/2015-02-18 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][], [Lars][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | [lars]: https://github.com/larsbak 7 | 8 | ## Tear-offs 9 | 10 | Gilad took his tear-off proposal and converted it into [a Git repo][tear-offs]. 11 | He markdown-ified the original Google doc, but didn't follow [the 12 | template][template] since the doc was already written. 13 | 14 | He put the spec changes right in the proposal doc instead of a separate `.tex` 15 | to play the part of a normal DEP author where the spec verbiage will get pulled 16 | out later. 17 | 18 | The committee seems generally happy with the proposal, though I'm not sure if 19 | everyone has looked at it in detail. 20 | 21 | [tear-offs]: https://github.com/gbracha/generalizedTearOffs 22 | [template]: https://github.com/dart-lang/dart_enhancement_proposals/blob/master/DEP%20Template.md 23 | 24 | ## Package specs 25 | 26 | Lasse has started converting his proposal into [a DEP repo][pkgspec]. We 27 | haven't looked at it in detail yet. We'll go over it in more depth next week. 28 | 29 | [pkgspec]: https://github.com/lrhn/dep-pkgspec 30 | 31 | ### Locating package specs 32 | 33 | The proposal as currently stated will get rid of the primary "packages" 34 | directory in each package and the symlinks it contains. What it doesn't address 35 | is the secondary symlinked "packages" directories that get created in a 36 | package's directories (`bin`, `test`, etc.) Lars would like to address those 37 | too, which I whole-heartedly agree with. 38 | 39 | Kasper noted that when an app is run by a tool like the Editor, it's easy for 40 | us to just inject the explicit package-spec path so the VM can find it. 41 | 42 | I agreed with that, but it still leaves a rough user experience when a user is 43 | running an app directly from the command-line. I suggested the VM could walk up 44 | directories looking for a package spec file. 45 | 46 | Kasper said that isn't desirable in some cases, like serving an app over HTTP, 47 | but could work if we limit it to apps run from local files. I think that 48 | limitation is fine. 49 | 50 | We discussed a bit about how to handle symlinks when doing this but didn't 51 | reach a conclusion. Kasper thinks most shells use `$PWD` to implement `cd ..` 52 | and that allows them to treat symlinked directories more or less like normal 53 | directories. 54 | 55 | ### Syntax 56 | 57 | We spent some time discussing the syntax. The VM wants something very very 58 | simple to parse since they have to implement it and it's in the path of app 59 | startup. 60 | 61 | I said something more open-ended and extensible might let us unify the package 62 | spec and lockfile. Lockfiles have more data in there that the package spec 63 | doesn't care about but if the format was open-ended, we could put it in there 64 | and have other tools just ignore it. 65 | 66 | Lars brought up that a package-spec will have absolute paths to things in the 67 | user's cache, so you wouldn't want to check that into source control anyway. 68 | Given that (which is absolutely right), it doesn't make sense to unify those 69 | files, so we can probably keep the syntax dead simple. 70 | 71 | We'll spend some time discussing this and be ready to talk more about it next 72 | week. 73 | 74 | ## Metaclasses 75 | 76 | After the last meeting Florian brought up that the propsal will have some 77 | negative size impact in dart2js, but we don't know how much. 78 | 79 | Kasper volunteered to do a simple experiment to get a pessimistic worst case 80 | size impact. If that isn't too bad, then we're in good shape. If it is, we may 81 | have to do more investigation to see if we can bring that size down. 82 | 83 | ## Other stuff 84 | 85 | * Gilad brought up that the VM team doesn't have direct representation in the 86 | DEP committee meetings, which we may want to address. 87 | 88 | * We're ready for the team to write more DEPs and get more in the pipeline. 89 | -------------------------------------------------------------------------------- /Meetings/2015-02-25 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Anders][], [Bob][], [Gilad][], [Ivan][], [Kasper][], [Lars][], [Lasse][]. 2 | 3 | [anders]: https://github.com/anders-sandholm 4 | [bob]: https://github.com/munificent 5 | [erik]: https://github.com/eernstg 6 | [gilad]: https://github.com/gbracha 7 | [ivan]: https://github.com/iposva-google 8 | [kasper]: https://github.com/kasperl 9 | [lars]: https://github.com/larsbak 10 | [lasse]: https://github.com/lrhn 11 | 12 | ## TC52 Meeting 13 | 14 | TC52 met this week. Gilad promised a final proposal for [generalized 15 | tear-offs][] will be ready for them by the next meeting on March 19th. He 16 | showed them the repo with the current proposal. 17 | 18 | [generalized tear-offs]: https://github.com/dart-lang/dart_enhancement_proposals/issues/3 19 | 20 | Anders reviewed the DEP process and how its role relates to theirs. The TC52 21 | folks are all happy to assist. 22 | 23 | I asked what the status of tear-offs is since it's considered "accepted" but 24 | Gilad mentioned there may be some changes based on Lasse's feedback. It *is* 25 | accepted, which means it's been forwarded to TC52, but there may be some minor 26 | adjustments there. 27 | 28 | ## [Package spec][] 29 | 30 | [package spec]: https://github.com/dart-lang/dart_enhancement_proposals/issues/5 31 | 32 | This is an initiative to eliminate the symlinks we create to deal with 33 | "package:" imports. There are two flavors of symlinks: 34 | 35 | 1. Pub creates a real "packages" directory in the root of your package. It 36 | contains a symlink for each package your app depends on, pointing to that 37 | package's real location. 38 | 39 | 2. Then, in all of the subdirectories in your app that may contain a Dart 40 | entrypoint, we make secondary symlinks that point to that main "packages" 41 | directory. 42 | 43 | Having an explicit package specification file that tells Dart explicitly where 44 | to find a package removes the first kind. We also want to eliminate the 45 | secondary ones. (They're particularly annoying to users since they clutter up 46 | their application's directories.) 47 | 48 | What we need to discuss now are: 49 | 50 | 1. The syntax for the file. 51 | 2. How tools find the file so that we can address point #2 above. 52 | 53 | Then we took these and discussed them out of order: 54 | 55 | ### Locating the package spec 56 | 57 | It will be a file on disc in the project's root directory—the same place 58 | the main "packages" directory which it replaces appears now. 59 | 60 | However, the VM doesn't know what a "project" or "package" is. It doesn't 61 | currently know how to find that. If you run an entrypoint that happens to be in 62 | the root directory, this works. But if it's in a subdirectory, it won't. 63 | (That's why we currently make all of the secondary "packages" symlinks.) 64 | 65 | One fix would be to have the VM walk up subdirectories until it finds a package 66 | spec. It's ugly, but it works. 67 | 68 | If a Dart program is run from the IDE, the IDE can provide an explicit path to 69 | the package spec. For web apps, the dev server can emulate the existing 70 | behavior. It's only if the user directly invokes the VM from the command line 71 | that we want to crawl back to find the file. 72 | 73 | ### Syntax 74 | 75 | It's a file on disc. It contains a mapping from strings to string. The key is 76 | the first path component of a "package:" URL and the value is the base URL that 77 | the rest of that package's path should be resolved against. The value can be a 78 | path or even an HTTP URL. 79 | 80 | One suggestion is to make the syntax a Dart map literal or to use some larger 81 | subset of Dart syntax. That should hopefully let the VM reuse its existing C++ 82 | Dart parser for it. 83 | 84 | ### How does it come into play? 85 | 86 | We discussed when this file needs to be parsed by the VM. Since even the 87 | entrypoint URL passed to the VM can use "package:", it will be before it 88 | executes any user code. 89 | 90 | ### How does a user make use of it? 91 | 92 | Pub will generate it for the user after running pub get/upgrade, just like it 93 | does with the lockfile. We don't expect users to hand-edit it. The first line 94 | will say something along the lines of: 95 | 96 | ``` 97 | This was generated. Keep your dirty fingers away from it. 98 | ``` 99 | 100 | (Maybe not quite so harsh.) 101 | 102 | It is with a heavy heart that we accept this means adding a third file to the 103 | top level of the user's package. It has some key differences from both the 104 | pubspec and lockfile, so we can't unify it with either. 105 | 106 | However, it does let us get rid of the "packages" directory at the top level, 107 | so the number of generated entries is the same. 108 | 109 | ### How does it work internally? 110 | 111 | We have internal customers that sometimes need to map a package to multiple 112 | directories that are overlaid on top of each other. Within a single package, 113 | one file may be physically located in directory A while another comes from B. 114 | Basically, they need search paths. 115 | 116 | This proposal doesn't help that. That may be OK—we could consider that 117 | out of scope. But we could try to do something. 118 | 119 | One option would be to let the user provide an imperative location procedure 120 | instead of a declarative package spec. Then they could implement their own 121 | search-path-like behavior. 122 | 123 | Other options: 124 | 125 | * The VM could allow multiple package specs and search them in order. 126 | * We could allow multiple entries for the same key in the package spec. 127 | 128 | Our current feeling is to make the right design for the general case and then 129 | try to find a not-too-terrible hack to help here. 130 | 131 | We agree a file is a good solution. Ivan, Florian, Dan Rubel (who works on the 132 | analyzer) and Bob will figure out a syntax they all agree on. 133 | 134 | ## Other DEP proposals 135 | 136 | We're still looking for more proposals to put into the pipeline. 137 | 138 | Gilad mentioned a proposal for null-aware operators at the TC52 meeting. It's 139 | simple enough that he thinks we can get something accepted and ready for them 140 | at the March meeting. 141 | 142 | Gilad will write up a DEP. It's got: 143 | 144 | * A `?.` safe navigation or "Elvis" operator. 145 | * A `??` null coalescing operator. 146 | * A `?=` operator that assigns only if the RHS is not null. 147 | 148 | ## [Metaclasses][] 149 | 150 | [metaclasses]: https://github.com/dart-lang/dart_enhancement_proposals/issues/4 151 | 152 | Kasper looked into how the metaclass proposal would affect generated JS size in 153 | dart2js. The short answer is that it doesn't look bad enough to rule out the 154 | proposal. It seems to be relatively easy to keep track of the use of 155 | metaclasses. 156 | 157 | One worrisome thing is that if you call `runtimeType` on anything, dart2js may 158 | lose track of which runtime types are being used. That can mean it ends up 159 | having to hold onto static methods in the generated code since it can't tell 160 | that they aren't in use. 161 | 162 | However, there don't seem to be many static methods in the code they looked at, 163 | and most of them already are being used. So not tree shaking them is probably 164 | not a large change. 165 | 166 | So, at least for codebases that they looked at, this feature doesn't seem to 167 | have a large impact. Now we need to evaluate the proposal to see if we like it. 168 | 169 | ## Configurable imports 170 | 171 | Lasse has a proposal for this but it's not on GitHub yet. Gilad also has a 172 | configurable library proposal but Lars doesn't think it addresses the same 173 | problem. Lasse's proposal addresses our most pressing concern: keeping the 174 | configuration hidden from the user. (Conversely, Gilad's proposal addresses 175 | other problems which Lasse's doesn't.) 176 | 177 | Lasse will DEP-ify this and send it out. We'll discuss it more next week. 178 | 179 | ## Agenda for next week 180 | 181 | What's on the table? We can talk about metaclasses, but we've also got 182 | null-aware operators and configurable imports. Lars thinks the operators are a 183 | slam dunk so we'll do those first, then configurable imports and then if we run 184 | out of time, we'll let metaclasses slip. 185 | 186 | ## Opening the DEP process up the public 187 | 188 | We talked about it some more. We've got a bit more documentation clean up to do 189 | and then it's ready to launch. We're aiming for sometime next week. 190 | -------------------------------------------------------------------------------- /Meetings/2015-03-04 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Anders][], [Bob][], [Gilad][], [Ivan][], [Kasper][], [Lars][], [Lasse][]. 2 | 3 | [anders]: https://github.com/anders-sandholm 4 | [bob]: https://github.com/munificent 5 | [erik]: https://github.com/eernstg 6 | [gilad]: https://github.com/gbracha 7 | [ivan]: https://github.com/iposva-google 8 | [kasper]: https://github.com/kasperl 9 | [lars]: https://github.com/larsbak 10 | [lasse]: https://github.com/lrhn 11 | 12 | ## [Null-aware operators][] 13 | 14 | [null-aware operators]: https://github.com/dart-lang/dart_enhancement_proposals/issues/9 15 | 16 | Gilad has a [DEP out on GitHub][null] for this now. It adds three new operators 17 | to Dart, each more wonderful than the last. All of them are syntactic sugar 18 | with simple, completely local transformations to existing Dart semantics. 19 | 20 | [null]: https://github.com/gbracha/nullAwareOperators 21 | 22 | This is one of our oldest (#41!) and most highly-starred (103!) 23 | [bugs][null bug], so we think people will like it. 24 | 25 | [null bug]: https://code.google.com/p/dart/issues/detail?id=41 26 | 27 | The careful eyes of the DEP committee noticed that the transformation for one 28 | of the operators was wrong as was one of the examples. Nothing gets past us. 29 | [Gilad has since [fixed it][fix].] 30 | 31 | [fix]: https://github.com/gbracha/nullAwareOperators/commit/39a336b3fb8bb7b59cdba59f8f1a35b177fbd020 32 | 33 | Gilad has spec language for this already. The main question is where it fits 34 | into the grammar. That should be clear by the time someone writes a parser for 35 | it. 36 | 37 | A couple of corner case questions: 38 | 39 | * Can `?=` be used in a constructor initialization list? **No.** Initialization 40 | lists don't allow any compound assignment operators. They're not just 41 | assignment; they have their own grammar production entirely. 42 | 43 | * Can the Elvis (`?.`) operator be used with cascades? **No**, we don't have 44 | any plan to support that. 45 | 46 | ### Motivation 47 | 48 | Erik brought up that we could add a motivation section if we want. It's 49 | motivated by the philosophical perspective that if a thing is absent, then any 50 | part of that thing is also simply absent as well. If you don't have a house, 51 | you can't get to its door either. 52 | 53 | I mentioned that I'm looking forward to `null` coalescing because it makes 54 | field initialization simpler in many cases. 55 | 56 | The Angular guys also want the Elvis operator. Previously, Angular templates 57 | expressions treated all `.` operators like this. For Angular 2, they are moving 58 | away from that to line up with Dart semantics. Having an explicit `?.` operator 59 | will let users get that behavior back when they want it. 60 | 61 | There's clear user demand for it and we're in agreement about the proposal. We 62 | haven't formally accepted it just yet because we'd like to give the public a 63 | chance to provide feedback. But, we expect we'll accept this at next week's 64 | meeting unless something surprising comes up. 65 | 66 | ## Public DEP process 67 | 68 | Speaking of which, during the meeting, others on the team flipped the private 69 | bit and sent out the announcement making the DEP repo and the entire process 70 | public. 71 | 72 | ## [Configured imports][] 73 | 74 | [configured imports]: https://github.com/dart-lang/dart_enhancement_proposals/issues/6 75 | 76 | Before we get into the details of the proposal, a high level framing question: 77 | Should a program's configuration be able to affect the *static* shape of the 78 | code, or just its runtime behavior? 79 | 80 | [Remark from Erik: If we do want to consider something like the "static shape" 81 | of an import, we ought to keep in mind that this concept is very similar to 82 | that of a structure/functor *signature* in ML. If libraries were first-class 83 | objects, they'd have classes, and they would in turn introduce library types, 84 | and then we could declare the library type for each configurable import and 85 | check that all the possible actual imports at that point do conform to this 86 | library type. This is rather heavy, of course, which is the reason why I was 87 | setting out from a simple, typeless model where there is no static shape 88 | machinery, just a naive enumeration of all possible configurations.] 89 | 90 | I think answering that helps guide us towards a solution. The two answers have 91 | different consequences: 92 | 93 | * If configuration can affect the static shape, then the analysis story gets 94 | more complex. 95 | 96 | * If it can't, then awareness of configuration, and configuration-specific code 97 | gets pushed later into the runtime where we might not want it. 98 | 99 | For example, the current patch file mechanism that the core libraries use 100 | guarantees the same API across all platforms. This lets the analyzer see one 101 | configuration for the core libraries. 102 | 103 | This proposal is not like that. At *runtime* you will only ever import one of 104 | them. That means warnings and what's malformed type are all based on what the 105 | import resolved to. What goes into the namespace is based on what configuration 106 | was actually chosen. 107 | 108 | However, *tools* can see all URIs simultaneously. The proposal does make the 109 | *set* of URIs statically known. It's not open ended, so the IDE can still see 110 | all of them. But it has to try to "union" them together and see how they 111 | overlap. 112 | 113 | [Remark from Erik: There are different tools: A compiler should probably not 114 | generate all variants in any setup with configurable imports (or any other 115 | special case of software product lines), it typically accepts configuration 116 | specifications ('-D') and compiles a single variant. "Partial compilers" 117 | (dart2dart) might translate a program using conditional compilation directives 118 | into an equivalent program using equivalent conditional compilation directives. 119 | An analyzer might cover all variants simultaneously, either by iterating over 120 | all variants internally every time it is relevant, or by some conservative 121 | approximation (e.g., by just considering one "static shape" when all potential 122 | imports have or conform to that same shape).] 123 | 124 | For example, what happens if two configurations have a member with the same 125 | name but different type? What does that do to auto-complete? 126 | 127 | [Remark from Erik: This issue extends beyond typing and into semantics: 128 | Considering an expression `x.y`, `x` might be a class or a variable name, and 129 | `y` might be a static method name or an instance method or getter, so `x.y` 130 | might be a getter invocation or a static method tear-off, etc.etc.] 131 | 132 | The proposal lets you shoot yourself in the foot if configurations don't line 133 | up. But it *does* give a real solution to the platform-specific code problem. 134 | 135 | One option is that the IDE could ask the user to pick configuration and then it 136 | analyzes the program in that context. That's what, for example, Visual Studio 137 | does if you happen to use `#if` in C#. 138 | 139 | Our concern is that then users end up committing code that only works in one 140 | configuration because they didn't remember to check and test the others. 141 | 142 | If all of the configurations expose the same API, everything works. But the 143 | proposal doesn't *ensure* that, which is a concern. We want some feedback from 144 | the analyzer folks about this. 145 | 146 | An alternate proposal that floated around a while back was to just make all 147 | "dart:" libraries available (but sometimes empty) on all implementations. So, 148 | for example, you could successfully import "dart:html" on the standalone VM and 149 | get the right types, but they would throw `NotImplementedError` at runtime if 150 | you tried to call them. 151 | 152 | Lars and others on the committee aren't a fan of that. It's nice to be able to 153 | reliable strip code out that you aren't using. From Angular, we have some 154 | experience that we can't rely entirely on tree-shaker to do this automatically. 155 | It's good that this proposal lets you explicitly cut code out. 156 | 157 | You can look at it like the C preprocessor in that it lets you statically 158 | remove code, which is good for controlling what you deploy. But, then, it also 159 | has much of the complexity of implementing an IDE for C that has to reason 160 | about code that is using the preprocessor. 161 | 162 | We ran out of time here, so we'll resume this next week. Stay tuned, folks 163 | … 164 | -------------------------------------------------------------------------------- /Meetings/2015-03-11 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][], [Lars][], [Lasse][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [erik]: https://github.com/eernstg 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | [lars]: https://github.com/larsbak 8 | [lasse]: https://github.com/lrhn 9 | 10 | ## Narrower DEP Meetings 11 | 12 | The [configured imports][] proposal has significant analysis implications, so 13 | we talked about having [Brian][] join the meetings. The attendee list is 14 | already getting quite large, and it's increasingly hard to be efficient. 15 | 16 | [configured imports]: https://github.com/dart-lang/dart_enhancement_proposals/issues/6 17 | [brian]: https://github.com/bwilkerson 18 | 19 | Instead of adding yet another warm body, the plan is to cut the core DEP team 20 | down to: 21 | 22 | * Bob 23 | * Gilad 24 | * Kasper 25 | 26 | They will then invite other attendees in to discuss specific proposals as they 27 | see fit. This should keep the DEP meetings more focused. 28 | 29 | For longer design discussions, our hope is that authors of proposals will 30 | arrange and have those meetings themselves with the right stakeholders. 31 | 32 | ## [Null-aware operators][] 33 | 34 | [null-aware operators]: https://github.com/gbracha/nullAwareOperators 35 | 36 | Sean Eagen [suggests][6] changing `?=` to `??=` for consistency with other 37 | compound assignment operators. We all agree. 38 | 39 | [6]: https://github.com/gbracha/nullAwareOperators/issues/6 40 | 41 | Including that change, this DEP is now accepted and on its way to TC 52. 42 | 43 | ## [Configured imports][] 44 | 45 | Since the current proposal seems to be getting complex around its static 46 | analysis story, [I][bob] wanted to sketch out [a rough idea][external] for 47 | something that's simpler to analyze. 48 | 49 | [external]: https://github.com/munificent/dep-external-libraries/blob/master/Proposal.md 50 | 51 | It avoids the problem of having to "union" multiple libraries together to 52 | determine how the analyzer sees them. However, it also has complexity regarding 53 | what it means to combine an external library with the canonical one. It may be 54 | that as that gets more fully-specified, it ends up as complex as the configured 55 | imports proposal. 56 | 57 | The basic question is still do we want configuration to affect the static shape 58 | of the program or not? 59 | 60 | If so, we'll have to figure out what the tooling story is. C/C++ IDEs do allow 61 | this using the preprocessor and then just require the user to select which 62 | configuration they're currently looking at. 63 | 64 | And, in fact, something like C#'s `#if` would be both a simple and powerful 65 | solution to this problem. But Lars and others definitely don't like that 66 | approach. We really want a library to have a single configuration-independent 67 | API. 68 | 69 | If users have to select a configuration, it's too easy for them to not check 70 | one and have configuration-specific bugs. 71 | 72 | Since the external libraries strawman is still half-baked it needs more work 73 | before we can see how it compares. We'll iterate on both in parallel and see 74 | where they end up. 75 | 76 | Lasse and I and the relevant stakeholders will work together "offline" (i.e. outside of official DEP meetings) on this. I'll talk to the analyzer folks in particular to see how they feel about this. 77 | -------------------------------------------------------------------------------- /Meetings/2015-03-18 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | ## Configuration-specific code 8 | 9 | We have something like 3 1/2 proposals floating around: 10 | 11 | * [Configured imports](https://github.com/dart-lang/dart_enhancement_proposals/issues/6) 12 | * [Configured imports (simplified)](https://github.com/dart-lang/dart_enhancement_proposals/issues/19) 13 | * [Import when](https://github.com/nex3/dep-import-when) 14 | * [External libraries](https://github.com/munificent/dep-external-libraries) 15 | 16 | We'd like the committee to have something to look at, but it doesn't seem like 17 | this area is ready to make any decisions yet. We'll let the stakeholders sort 18 | it out in other forums (email, GitHub, etc.) and then get back to us when 19 | things are more settled. 20 | 21 | ## DEP meetings 22 | 23 | We're still learning how to best manage the DEP process and these weekly 24 | meetings, and figure out what they're for. One option is that these meetings 25 | are just for making decisions on a proposal after its solid. 26 | 27 | For the detailed design work that leads up to that, we'd encourage people to 28 | have meetings, discussions, pow-wows or whatever they want outside of this 29 | meeting. We can be involved in those too of course. 30 | 31 | One risk is that if too much work happens where we don't see it, we may not 32 | have enough context to make good decisions. Or maybe it will just be harder for 33 | us to wrap our heads around and accept a proposal that we aren't intimately 34 | familiar with. 35 | 36 | Hopefully authors will capture all of the salient context in the proposal 37 | itself. Our guess is that this will be a longer process. We do want the overall 38 | velocity of Dart to be higher. The trick will be getting that with a more 39 | distributed process. 40 | 41 | The real challenge is getting these proposals to all fit together if they are 42 | coming from different groups. Our role then is to make sure Dart works 43 | holistically. 44 | 45 | ## Iterating on proposals 46 | 47 | We could go through each proposal in the meeting and give feedback. Then wait 48 | and see how they respond. By itself, that's not going to be effective. It will 49 | take too many iterations to getting something solid. 50 | 51 | Instead, we'll need to continually monitor proposals on the side and give 52 | feedback. For example, Gilad has already started working with [Leaf][] on his 53 | [generic methods][] proposal 54 | 55 | [generic methods]: https://github.com/dart-lang/dart_enhancement_proposals/issues/22 56 | [leaf]: https://github.com/leafpetersen/dep-generic-methods 57 | 58 | Wanting a high velocity makes it hard to get things perfectly right. We'll 59 | probably have to accept that proposals should be reasonable but may still be 60 | tweaked until it's been implemented and all of the issues have been flushed 61 | out. 62 | 63 | ## Experimental implementations 64 | 65 | Something that would help is being able to implement a proposal while it's 66 | still "in flight". Last year, Lars shared an idea with the team to enable us to 67 | have "experimental" implementations that are hidden behind an opt-in flag. 68 | 69 | All tools (VM, dart2js, analyzer, etc.) would handle this flag. Users could 70 | enable it to try out new things with the understanding that experimental 71 | features may and likely *will* have breaking changes. 72 | 73 | We got sort of hung up on things like "does the stable channel enable 74 | experiments?" and "can packages on pub require experimental features?" so it 75 | didn't get far but it sounds like it's time to bring this idea back. 76 | 77 | Kasper will talk to Lars about it and get his thoughts. 78 | 79 | We do have to be careful that experiments don't become a vector for shoehorning 80 | stuff into the language. If an important customer relies on some experiment, we 81 | don't want to end up forced into keeping it. At the same time, knowing that an 82 | experimental feature is used by an important customer is useful data to have. 83 | 84 | There's just a risk that we implement an experiment in some hacked together way 85 | and then become unable to clean it up if users rely on the nasty edge case 86 | behavior. 87 | 88 | Another potential problem is this runs the risk of making proposals from 89 | authors not on the Dart team second class since they don't have the luxury of 90 | submitting an experimental implementation. Hopefully, though, they will have 91 | champions on the team who are excited enough about the proposal to help out. 92 | And, if we know it's going to be gated behind an experimental flag, we're more 93 | comfortable landing patches from an external contributor. 94 | 95 | ## Breaking changes 96 | 97 | So far, we've been focused on changes that are strict additions to the 98 | language. We haven't considered breaking anything, and in general, we don't 99 | want to. But there may come a time when we want to. Over the next few quarters, 100 | we should think about what that means and have some sort of plan. 101 | 102 | If we realize we made some decision in the past and it's hard to live with now, 103 | what can we do? If we want to make a breaking change, do we agonize over each 104 | tiny one, or do a big "Dart 2.0" and ship a batch of them? How do we manage the 105 | transition for our users? 106 | 107 | ## Next week's meeting 108 | 109 | We'll invite [Lasse][] and [Ivan][] and go over the [package spec][] proposal. 110 | 111 | [package spec]: https://github.com/dart-lang/dart_enhancement_proposals/issues/5 112 | [lasse]: https://github.com/lrhn 113 | [ivan]: https://github.com/iposva-google 114 | 115 | There are still a few [open issues][] from the last time we discussed it. We 116 | can try to settle them in the meeting itself, but it's probably better to try 117 | to get those hammered out offline before the meeting. 118 | 119 | [open issues]: https://github.com/lrhn/dep-pkgspec/issues 120 | 121 | I'll bug Lasse and see if we can reach decisions on them and update the 122 | proposal. 123 | 124 | ## More proposals 125 | 126 | The configuration stuff still needs work. We need to pare down the variants. 127 | 128 | At some point, Gilad intends to write proposals for union types, some changes 129 | to type promotions, and some unspecified stuff. Leaf's [generic methods][] 130 | proposal is coming soon. *[As of this writing, it's out now.]* 131 | 132 | What about expanding the set of places where metadata annotations are allowed? 133 | That would help the dev compiler folks. In principle, we'd like to allow them 134 | everywhere. In practice, it's hard to fit that into the spec. Function types in 135 | particular make it harder. 136 | 137 | (Function type syntax is something where it might be nice to have the luxury of 138 | making a breaking change to fix.) 139 | 140 | There's no shortage of proposals to work on. There may just be a shortage of 141 | things that are ready for the committee to see. That's OK. It might just take a 142 | while to pile up again. 143 | -------------------------------------------------------------------------------- /Meetings/2015-03-25 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | ## [Package spec] 8 | 9 | [package spec]: https://github.com/dart-lang/dart_enhancement_proposals/issues/5 10 | 11 | ### Syntax 12 | 13 | [Lasse][] updated the proposal based on some discussions he had with [Ivan][]. 14 | Ivan signed off on a simple key/value mapping. No YAML, no Dart syntax, no Java 15 | property file. 16 | 17 | [lasse]: https://github.com/lrhn 18 | [ivan]: https://github.com/iposva-google 19 | 20 | Also Lasse fixed the reference to the spec, which was incorrect. 21 | 22 | The feeling on the committee is that a dumb key/value mapping—think an 23 | INI file—isn't satisfying. It doesn't give us any wiggle room for future 24 | extensions. We have some internal users who may want this extended in the 25 | future for their needs and this doesn't help there. 26 | 27 | Gilad suggested we could put a version number at the top of the file, but that 28 | doesn't feel much better. We could just use a different file name at that 29 | point. 30 | 31 | YAML is nice in that we use it for other things, but it isn't trivial to parse. 32 | Kasper wondered if Ivan would accept something more like a named Dart map 33 | literal. According to Gilad, the VM isn't set up to reuse that part of the 34 | parser right now. 35 | 36 | We'd love it to be Dart syntax. It gives us a reasonable file extension, 37 | editors can syntax highlight it, etc. Maybe we could just specify a very 38 | restricted grammar but using the same scanner. 39 | 40 | It would be a strict subset of Dart syntax. Reusing the lexical grammar gives 41 | us most of the value: it takes care of encoding, whitespace, comments, 42 | escaping, etc. 43 | 44 | Writing a new parser for a limited set of tokens should be pretty easy. This 45 | would be easier to extend, and easier to specify. 46 | 47 | *[I][bob] will update the [relevant bug][syntax bug] with our suggestion.* 48 | 49 | [syntax bug]: https://github.com/lrhn/dep-pkgspec/issues/1 50 | 51 | We still aren't sure what the long-term picture for the file is. Would we 52 | eventually want to be able to put other constants in there that become part of 53 | the program's constant environment? We don't need to answer this, but it's 54 | interesting to consider. 55 | 56 | Either way, if this is a file that other tools and the ecosystem will build 57 | around, it should be stable and extensible. We're thinking a constant with a 58 | named value. Something like: 59 | 60 | ```dart 61 | const packages = { 62 | "args": "../../args", 63 | "unittest": "/Users/bob/.pub-cache/hosted/pub.dartlang.org/unittest/lib/" 64 | }; 65 | ``` 66 | 67 | This makes it a valid Dart library. Other libraries could even possibly import 68 | it. 69 | 70 | ### [Walking up directories][dirs] 71 | 72 | [dirs]: https://github.com/lrhn/dep-pkgspec/issues/3 73 | 74 | Ivan says walking up directories to look for a package spec doesn't work for 75 | HTTP entrypoints. We say fine, only do it for file URLs. 76 | 77 | The command line VM has to do this or package specs aren't a useful feature. 78 | The initial motivation is to eliminate symlinks. If we don't walk up 79 | directories, then we can't eliminate the symlinks in package subdirectories. 80 | 81 | However, this behavior doesn't necessarily have to be in the *language spec*. 82 | It's just that all of the teams and tools need to agree to implement it. From 83 | the spec's perspective we can just say this behavior is implementation 84 | dependent. 85 | 86 | Pulling this behavior out of the spec may be good for people like the [Sky][] 87 | folks who have their own Dart embedder. This behavior may not make sense for 88 | them and we don't want them to be shoehorned into it. 89 | 90 | [sky]: https://github.com/domokit/sky_sdk/ 91 | 92 | Our thought then is to pull this out of the spec but have something like an 93 | annex that describes it and that the tools all agree to follow. This is similar 94 | to the core libraries in many ways: they aren't specced but dart2js, the 95 | analyzer, and the VM agree to be compatible. 96 | 97 | We *do* want describing and agreeing on this behavior to be part of the *DEP*, 98 | though. The agreement won't end up in the spec, but it still needs to happen. 99 | 100 | ### File name 101 | 102 | I noted briefly that "pkg" isn't used anywhere else in our tooling, so 103 | "package" or "packages" probably makes more sense. 104 | 105 | ## Next week 106 | 107 | Kasper will invite Ivan and Lasse just in case we don't get everything resolved 108 | on the bug tracker by next week's meeting. 109 | 110 | The [generic methods proposal][] is a complex beast, so we're still chewing on 111 | that. 112 | 113 | The stuff around [configuration][] is still pretty unformed and isn't ready for 114 | the committee meeting yet. We'll keep working on that outside of the meeting 115 | for now. 116 | 117 | [generic methods proposal]: https://github.com/dart-lang/dart_enhancement_proposals/issues/22 118 | [configuration]: https://github.com/dart-lang/dart_enhancement_proposals/issues/6 119 | -------------------------------------------------------------------------------- /Meetings/2015-05-06 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | 6 | *Note: we skipped several weeks of meetings due to the [Dart Summit][].* 7 | 8 | [dart summit]: https://www.dartlang.org/events/2015/summit/ 9 | 10 | Kasper was out this week due to some family commitments, so today's meeting 11 | was, I suppose, 1/3 less official than other meetings. 12 | 13 | ## [Package spec][] 14 | 15 | [package spec]: https://github.com/dart-lang/dart_enhancement_proposals/issues/5 16 | 17 | We hoped to convince [Ivan][] to accept a restricted subset of Dart syntax for 18 | the file, but were unable to. Instead, we'll go with the previous INI-file-like 19 | syntax. 20 | 21 | [ivan]: https://github.com/iposva-google 22 | 23 | The remaining concerns for the proposal are what to name the file, and how the 24 | proposal interacts with the language spec. The proposal has two options here. 25 | Gilad's preference is to choose the option that says "package:" is 26 | implementation-defined and remove the details of its semantics from the spec 27 | entirely. He'll file an issue to that effect. 28 | 29 | For the file name, there is an [open bug][file name] on that that we'll track. 30 | 31 | [file name]: https://github.com/lrhn/dep-pkgspec/issues/10 32 | 33 | This isn't blocking us from starting to implement the proposal in various 34 | tools. We'll just change the file name later if we have to. 35 | 36 | ## [Spaceship operator][] 37 | 38 | [spaceship operator]: https://github.com/dart-lang/dart_enhancement_proposals/issues/25 39 | 40 | Kenneth filed a proposal to add a `<=>` to Dart that's synonymous with 41 | `compareTo()`. Perl, Ruby, and Groovy have this. 42 | 43 | The quality of the proposal itself is great: it's precise, lucid, and 44 | semantically clear. However, we don't think the feature itself is a good fit 45 | for Dart. 46 | 47 | Unlike named methods, an operator can't be *read* to determine what it does. 48 | Where a user may have never encountered `compareTo()` before, the words 49 | "compare to" alone hint at what it does. If you've never encountered `<=>` 50 | before, "less than equals greater than" won't help you much. 51 | 52 | Also, each new operator introduces its own precedence and associativity rules 53 | that users need to understand to visually parse code. 54 | 55 | The rules of thumb I have for introducing an operator are: 56 | 57 | 1. It should be common from basic mathematics or other programming languages so 58 | that almost all readers will already be familiar with what it means. 59 | 60 | 2. It should be frequently-used enough make the brevity and more complex 61 | precedence table worthwhile. 62 | 63 | The spaceship operator is familiar to users of a few languages, but not to most 64 | (unlike, say `!` for negation). 65 | 66 | Also, `compareTo()` doesn't seem to be used very often. In a corpus of pub 67 | packages, I found 820 calls to `compareTo()`. There were 26x more uses of `<`, 68 | 13x more uses of `>`, and 73x more uses of `==`. 69 | 70 | Given that, it seems like the right choice is to leave this out and keep the 71 | language simpler. 72 | 73 | ## [Metaclasses][] 74 | 75 | [metaclasses]: https://github.com/dart-lang/dart_enhancement_proposals/issues/4 76 | 77 | This has been on the back burner for a while. In Kasper's absence, we can't 78 | officially move it forward, but we spent some time informally talking about it. 79 | 80 | Ian Hickson on the Sky team has brought the proposal up. Gilad's understanding 81 | is that he was looking for the metaclass inheritance hierarchy to match the 82 | regular class one. (In non-metaclass terms, this means roughly that 83 | constructors and static methods would be inherited.) I believe Hixie was hoping 84 | to avoid the headache of writing lots of forwarding constructors in derived 85 | classes. 86 | 87 | This is what Smalltalk does. It's one of the few corners of Smalltalk where we 88 | deliberately want to do something different in Dart and *not* have metaclass 89 | inheritance mirror the regular class inheritance. The Smalltalk way can be 90 | convenient, but it's bad in principle since it can make the superclass's 91 | factory interface leak into the subclass. 92 | 93 | (In other words, if Derived inherits from Base, that doesn't always mean you 94 | want the way you create a Base to be a valid way to create a new Derived.) 95 | 96 | So the metaclass proposal doesn't cover Hixie's use case. Instead, Gilad has 97 | asked him to try doing the work manually to see how painful it is. 98 | 99 | ### Static interfaces 100 | 101 | The problem I had with the initial proposal is that it gave you a dynamic 102 | object for the class, but didn't give you a way to statically type it. You 103 | couldn't declare that the metaclass implements an interface. 104 | 105 | Leaving that out of the proposal simplifies it, but it is a limitation. Since 106 | then, Gilad has started to fill that in. 107 | 108 | ### Size 109 | 110 | There is some concern that having metaclasses—effectively a pair of 111 | classes for each class definition—will have some unwanted size problems 112 | in the VM. This is especially a concern now that the VM folks are looking at 113 | precompilation and are starting to care more about code size. 114 | 115 | ### Reification 116 | 117 | The dev compiler folks (and I believe the VM folks too) have generally had pain 118 | related to reified generics. They add a decent amount of complexity, use 119 | memory, and don't always seem to provide much value in return. 120 | 121 | I asked if metaclasses could help here. 122 | 123 | Gilad said, yes, instead of using a reified *type* parameter at runtime, in 124 | many cases, you could just pass the class in as a *value* parameter. There's 125 | still the question of how the static type system sees it, so there's still some 126 | complexity there. 127 | 128 | But it simplifies the system: you don't have a parallel universe for passing 129 | both value and type parameters around at runtime. 130 | 131 | This would probably be a very long term change, but it might be nice to move in 132 | the direction towards more stratification between the static and dynamic 133 | behavior. 134 | 135 | ## [Interceptors][] and macros 136 | 137 | [interceptors]: https://github.com/sigmundch/DEP-member-interceptors 138 | 139 | Gilad talked to [Siggy][] about his interceptors proposal. Gilad would like to 140 | work on a more general macro proposal that would subsume that. Siggy also 141 | agrees that special-casing interceptors is a bit clunky. 142 | 143 | [siggy]: https://github.com/sigmundch 144 | 145 | Gilad is looking at the interceptors proposal then as a test case for a macro 146 | proposal. If the macro proposal can cover interceptors, that's a good sign. 147 | Even better, we can look at the full list of [transformers][] that Polymer and 148 | Angular are using now and see which of those could go away if we had macros. 149 | 150 | [transformers]: https://www.dartlang.org/tools/pub/assets-and-transformers.html 151 | 152 | Gilad will get in touch with [Kevin][] to coordinate with this. 153 | 154 | [kevin]: https://github.com/kevmoo 155 | 156 | ## [Static analysis of calls on functions][28] 157 | 158 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 159 | 160 | Lasse just filed this little proposal. Neither of us have looked at it yet, so 161 | we'll kick it to next week. 162 | 163 | ## Configuration-specific code 164 | 165 | There are a bunch of proposals floating around for this. After the summit, a 166 | few of us on the Dart team spent some time talking about [Erik's 167 | proposal][erik] and [external libraries][]. 168 | 169 | [erik]: https://github.com/eernstg/dep-configured-imports 170 | [external libraries]: https://github.com/munificent/dep-external-libraries 171 | 172 | Erik's proposal is a variant of Lasse's [configured imports 173 | proposal][configured] that clarifies some of the static analysis questions of 174 | the original. 175 | 176 | [configured]: https://github.com/dart-lang/dart_enhancement_proposals/issues/6 177 | 178 | External libraries is a strawman I sketched out which basically says, take the 179 | "patch file" mechanism we are already using to handle the platform-specific 180 | implementations of our core libraries (which need to bottom out at C++ on the 181 | VM and JS in dart2js) and clean that up and make it generally available. 182 | 183 | I'm obviously biased, but I think the idea got a warm enough reception at the 184 | meeting that I'll spend some time trying to flesh out the details. If I can 185 | find the time, I may experiment with implementing it in dart2js to see if it 186 | works for the core libraries. 187 | 188 | I'll also spend some time coordinating with Erik to see if the concerns he 189 | raised with the proposal can be addressed. 190 | 191 | ### Linking to code-genned files 192 | 193 | Another reason I'm interested in patch files is that they may help some of the 194 | code generation tools we've been looking at lately. We're going in a direction 195 | of using a tool to automatically generate code to implement things like 196 | serialization for types. 197 | 198 | That works well when the generated code is naturally in a separate file, but 199 | works less well when you want to generate code into the middle of a 200 | hand-authored class. 201 | 202 | Patch files could address that too. You'd basically declare an external method 203 | in your class and then codegen a separate patch file that fills that in. 204 | 205 | ## [Generic methods][] 206 | 207 | [generic methods]: https://github.com/dart-lang/dart_enhancement_proposals/issues/22 208 | 209 | Leaf's proposal is still ongoing. He's doing some work on it now. 210 | 211 | Concurrently, the analyzer folks may start adding at least parser support for 212 | it so we can start prototyping an implementation. 213 | 214 | ## Overloads 215 | 216 | Jacob is working on consuming TypeScript definition files in dart4web, which 217 | requires some way to handle TypeScript's notion of overloads in interfaces. 218 | Since this is just for the web and the VM doesn't have to worry about it, it 219 | may be fairly straightforward. 220 | 221 | Gilad talked to [Jacob][] about it at the Summit. Since Gilad is busy right 222 | now, we'll lean on Jacob to take a first stab at it. 223 | 224 | [jacob]: https://github.com/jacob314 225 | 226 | ## Mixins 227 | 228 | We have started discussions several times on lifting the restrictions on 229 | mixins, but it hasn't been a priority in the past. I believe I've heard from 230 | some customers recently about this so we may have some more reason to look at 231 | it now. Gilad will write some details up about it. 232 | -------------------------------------------------------------------------------- /Meetings/2015-05-13 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | ## [#5 Package spec][package spec] 8 | 9 | [package spec]: https://github.com/dart-lang/dart_enhancement_proposals/issues/5 10 | 11 | All the issues are closed. Some users added comments about using `.packages` as 12 | the file name after the relevant bug was closed, but I think those didn't make 13 | it under the wire. 14 | 15 | For the language spec itself, we'll change it such that it says "package:" is 16 | now left entirely up to the implementation to handle. Gilad will bring that 17 | change to TC52. 18 | 19 | All of the tools coming from the Dart team will implement the `packages.cfg` 20 | semantics in the proposal. 21 | 22 | So this one is accepted! 23 | 24 | *Note: After the meeting, based on user feedback, Lasse changed the file name 25 | to `.packages`.* 26 | 27 | ## [#28 Static analysis of calls on functions][28] 28 | 29 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 30 | 31 | We haven't all had a chance to look at this in detail yet, but we discussed it 32 | some. 33 | 34 | According to the spec, if you have an object whose static type is Function, it 35 | should cause a static warning to invoke it. There is sense in this. Since the 36 | Function class encompasses all functions, regardless of their arity or named 37 | parameters, your call may well not match the actual signature of the function. 38 | For example, this code will fail at runtime: 39 | 40 | ```dart 41 | Function f = (a, b) => "got $a and $b"; 42 | f("just one arg"); 43 | ``` 44 | 45 | The analyzer and dart2js don't currently implement this warning, so they each 46 | have a bug here. If they did implement this, though, a lot of warnings will 47 | appear in existing code. Most of the time, if you have a Function, you *do* 48 | invoke it after all. 49 | 50 | This DEP proposes tweaking the spec to not generate any static warnings if the 51 | type is Function and the method is `call`. You could think of Function as being 52 | "dynamic for calls" in the sense that wouldn't report static warnings related 53 | to calls, but would still give you static warnings if you called any other 54 | method on it that's not declared on the Function class. 55 | 56 | This is a trade-off. There are lots of potential bugs where you call a function 57 | with the wrong signature that will be masked by this. But it also avoids false 58 | positives where you'd get a warning even when the signature *is* correct. 59 | 60 | Of course, if you do want your invocations to be more tightly checked, you'd 61 | want to use an actual function type instead of just Function. 62 | 63 | I think the committee is OK with this in general, but Gilad wants to spend time 64 | on the spec wording. 65 | 66 | ## [#26 Full optional parameters][26] 67 | 68 | [26]: https://github.com/dart-lang/dart_enhancement_proposals/issues/26 69 | 70 | Currently, a method can have optional positional parameters or optional named 71 | ones, but not both. This proposal relaxes that limitation and allows a method 72 | to have both optional position and optional named parameters. 73 | 74 | There were some complexity concerns about this on the VM team, but they looked 75 | into it and it seems it isn't so bad. 76 | 77 | The proposed spec changes are a subset of the full list of things to change, so 78 | Gilad filed an issue about that. He'll work with [Lasse][] to get the full 79 | workup of spec changes. 80 | 81 | [lasse]: https://github.com/lrhn 82 | 83 | [Lars][] thinks it's generally a good thing. At a high level, it seems 84 | reasonable, aside from the general hesitancy to add more complexity. 85 | 86 | [lars]: https://github.com/larsbak 87 | 88 | We do worry it will be more painful to implement than we hope. Kasper thinks 89 | dart2js will struggle with this since there are places where we assume a method 90 | has one or the other kind of optional parameter but not both. 91 | 92 | In terms of priority, removing this limitation may not be as important as 93 | removing other limitations like those in mixins. 94 | 95 | So, the proposal needs some more spec work. In the meantime, we'd like 96 | implementors to start taking a look at this and let us know if it's going to be 97 | a problem. We do know this might be hard for DDC. 98 | 99 | ## Eliminating nested `const` in const expressions 100 | 101 | Lasse is working on a proposal for this, but he hasn't submitted it yet. We'll 102 | look at it more when he's ready for us too. 103 | -------------------------------------------------------------------------------- /Meetings/2015-05-20 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | ## [#28 Static analysis of calls on functions][28] 8 | 9 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 10 | 11 | We're fine with it. There's still some spec work to do. The easy stuff is 12 | there. There's a few more things that aren't there yet. Gilad will help out. 13 | 14 | Basically, we'll reinterpret `Function` as a magical type that describes all 15 | function types. 16 | 17 | ## The `const` brothers 18 | 19 | There are two DEPs out related to `const`. They haven't been officially sent to 20 | the committee yet, but people are talking about them on core-dev@. 21 | 22 | * Rasmus Eneman has a proposal for [constant function literals](https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/W9zZt9T4ciA) 23 | * Lasse has a proposal for [eliding `const` inside const expressions](https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/It2sBgpdIG8) 24 | 25 | I guess us looking about them now is jumping the gun, but why not? 26 | 27 | ### Constant function literals 28 | 29 | The main problem with allowing constant anonymous functions is that they cannot 30 | be closures over non-constant state. Rasmus addresses that by saying they are 31 | sugar for *top-level* functions. 32 | 33 | This ensures they aren't closures since they only have access to top-level 34 | scope. Doing this would probably work, but we think it will be confusing for 35 | users. For example: 36 | 37 | ```dart 38 | var a = "outer"; 39 | 40 | main() { 41 | var a = "inner"; 42 | var f = const () { print(a); }; 43 | f(); 44 | } 45 | ``` 46 | 47 | Assuming I understand the proposal correctly, this would print `"outer"` and 48 | not have any errors. This would probably be unpleasantly surprising. 49 | 50 | The function is at least clearly marked `const` so there's a way to see where 51 | this behavior is occurring. Of course, if we mix this with Lasse's proposal, 52 | that becomes no longer the case. 53 | 54 | We aren't sure if this is something we want to rush into. If it is something we 55 | want to do, we probably want something more complex than just saying it's in 56 | the top level scope. We would probably want to say it is in the scope where it 57 | appears, but closing over anything is some kind of error. 58 | 59 | ### Eliding `const` 60 | 61 | One of the things that users have repeatedly been annoyed by is the need to 62 | repeat `const` at every level of a constant expression. This code is wrong: 63 | 64 | ```dart 65 | const data = const [ 66 | { 67 | "widgets": [const Widget(1)] 68 | } 69 | ] 70 | ``` 71 | 72 | It has to be: 73 | 74 | ```dart 75 | const data = const [ 76 | const { 77 | "widgets": const [const Widget(1)] 78 | } 79 | ] 80 | ``` 81 | 82 | Lasse's proposal defines a "const context". Inside that, the keyword `const` 83 | can be left out. Metadata annotations, constant initializers, and default 84 | values are all const contexts, so the above can be: 85 | 86 | ```dart 87 | const data = [ 88 | { 89 | "widgets": [Widget(1)] 90 | } 91 | ] 92 | ``` 93 | 94 | This regularizes the special case where `const` can be omitted for the 95 | outermost constructor call of a metadata annotation. 96 | 97 | Gilad is generally against the idea of the same program text meaning something 98 | different in different contexts. He also brought up that this can make some 99 | code related to generics ambiguous. By leaving off the `new` or `const` in a 100 | constructor call, code like this: 101 | 102 | ```dart 103 | @A(B(d)) 104 | ``` 105 | 106 | Could interpreted in one of two ways: 107 | 108 | ```dart 109 | @A(B(d)) // Call constructor on generic class B with argument d, pass to A. 110 | @A(B < b, c > (d)) // Call constructor on A, passing two boolean arguments B < b, and c > (d). 111 | ``` 112 | 113 | The [generic method proposal][gen] has the same problem. It is a breaking 114 | change, but it's unlikely to occur in practice. 115 | 116 | [gen]: https://github.com/dart-lang/dart_enhancement_proposals/issues/22 117 | 118 | If we decide it's a direction we'll go in, we can start making our tools like 119 | the analyzer warn on this construct now to give people time to migrate. 120 | 121 | ## [#26 Full optional parameters][26] 122 | 123 | [26]: https://github.com/dart-lang/dart_enhancement_proposals/issues/26 124 | 125 | Gilad filed an issue that Lasse hasn't addressed yet to add some more spec 126 | details to the proposal. 127 | 128 | We're also waiting for feedback from the DDC folks to see how feasible they 129 | think it will be to implement this. So for now, we'll just kick it down the 130 | road. 131 | 132 | ## Mixins 133 | 134 | Not a DEP yet but Gilad wanted to start talking about this. He initially 135 | planned to resurrect his original proposal for mixins that didn't have the 136 | restrictions of the current language around `super()` calls and constructors. 137 | 138 | Since then, there has been some discussion about another way to enable checking 139 | `super()` calls. You could basically define the "superclass interface" for a 140 | mixin class. 141 | 142 | `super()` calls within the class would be checked against that interface. When 143 | the class is mixed in to another, we could check that that class's superclass 144 | also satisfies the interface. 145 | 146 | This might give us an easier path forward than doing the whole kit and 147 | caboodle. We're worried doing everything might take too long to implement. 148 | 149 | Kasper brought up that this takes us a step towards making mixins separate 150 | constructs from classes. Specifying a superclass interface means that the class 151 | is intended to only be used as a mixin. We're not sure if we want to move away 152 | from having everything—interfaces, classes, and mixins—unified 153 | under a single construct. 154 | 155 | Part of the problem is that a class definition creates two things and 156 | associates them with the same name: 157 | 158 | 1. The full class with all of its inherited members. This is what you get when 159 | you use it as a class or an interface. 160 | 161 | 2. The "delta" between this class and its superclass. In other words, just the 162 | members it itself defines. This is what you get when you use it as a mixin. 163 | 164 | People have to be aware of this distinction and understand which of the two 165 | they're getting where. Allowing mixins to have non-`Object` superclasses might 166 | make that more confusing. 167 | 168 | One idea Gilad had is to allow a mixin to have a superclass and/or 169 | superinterfaces. When you mix it in to another class, we could warn if the 170 | latter's superclass doesn't implement the mixin's superclass and 171 | superinterfaces. 172 | 173 | This would let users know they got #2 when they may think they got #1. It would 174 | get us a step closer to the full solution. 175 | 176 | Gilad will look into formulating a DEP for this. 177 | -------------------------------------------------------------------------------- /Meetings/2015-05-27 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | This week's meeting was a short one because I forgot about the Memorial 8 | Holiday, thought Wednesday was Tuesday, and ended up showing up fifteen minutes 9 | late. Sorry about that. 10 | 11 | ## [Non-nullable types and non-nullable by default][nnbd] 12 | 13 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 14 | 15 | If you haven't seen it, [Patrice's proposal][dep] is a stellar example of what 16 | a high quality DEP looks like. The whole committee hasn't read it in depth 17 | yet—it's about 50 pages—but we're working our way through it and 18 | filing issues or otherwise providing feedback. 19 | 20 | [dep]: https://github.com/chalin/DEP-non-null 21 | 22 | Gilad describes the proposal as, "fundamentally, this is doing it right". 23 | 24 | The high level question is whether it's something we want to do at all. It is a 25 | breaking change, of some sort. We do like that the proposal describes why and 26 | how it's a breaking change, and how to mitigate that. 27 | 28 | The question for us—for various definitions of "us"—is whether we 29 | will be happy with where we end up if we go through that migration process. If 30 | we think it's a worthwhile destination, we should start putting resources into 31 | figuring out how to get there. 32 | 33 | Historically, some people on the language team haven't been a fan of 34 | non-nullable types. There's a worry that they add a lot of complexity to users 35 | and you don't end up being able to avoid null anyway. 36 | 37 | At the same time, we are seeing users pulling Dart in a direction where they 38 | get more mileage out of their static types and non-nullable types might let us 39 | do that without changing some of the fundamental structure of the system. 40 | 41 | What impressed me about the proposal is how little change seems to be required 42 | to get to a world where non-nullable types are the default. That leads me to 43 | believe (and in the past I've gone through code to validate this) that most 44 | Dart code today doesn't work with null values. 45 | 46 | ### Experimenting 47 | 48 | In order to see if that impression is true, though, we'd have to implement the 49 | type rules and see how real-world Dart code fares under them. We'd want to do 50 | this without being actually committed to shipping it in the language. We'd have 51 | to conduct it as an experiment first. 52 | 53 | One concern is that nullable types end up being viral and spreading throughout 54 | your program, landing you right back where you started. If you've ever tried to 55 | make a large C++ program const-correct, you have an inkling of how this can go. 56 | 57 | A piece that would help is a tool that can automate converting from 58 | nullable-everywhere Dart code to the proposed non-nullable-by-default form and 59 | add in the nullable annotations as needed. We could do this either statically, 60 | or at runtime in checked mode, or maybe even both. 61 | 62 | For change of this magnitude, there are a couple of gates it has to go through: 63 | 64 | 1. Does the proposal have enough value to be worth putting real Dart team 65 | resources into doing some experimental implementations so we can validate 66 | the model? 67 | 68 | 2. If that pans out, do we want to commit to shipping it in the language? 69 | 70 | One initial step might be to add a flag to the VM to parse but ignore the 71 | syntax so experimental code using the new annotations runs as-is in the VM. 72 | Meanwhile, we can experiment with static analysis. 73 | 74 | If we decide to back out, it would be pretty simple to have an analysis server 75 | quick fix that just strips out the annotations. 76 | 77 | ### Syntax 78 | 79 | Gilad is slightly worried about the `!` syntax since it looks like a negation. 80 | I suggested maybe going postfix instead, but that may run into other collisions 81 | with operators. We could do postfix `!` and prefix `?` but that might be 82 | strange. 83 | 84 | ### Next steps 85 | 86 | I'll just quote Gilad directly here: "No one, externally or even internally has 87 | written something this outstanding. The proposal is really really good." 88 | 89 | We like it, but the change is a big one. 90 | 91 | There are two things to figure out: 92 | 93 | 1. Hammer out the little details around the syntax. The proposal makes good, 94 | concrete suggestions, but maybe we'll want to tweak them a bit. 95 | 96 | 2. Working together to put together a plan for how we could actually implement 97 | and run the experiment. And how to migrate the world if the experiment 98 | succeeds, or gracefully back out if we decide not to do it. 99 | 100 | A lot of the second point involves us on the Dart team. Figuring out 101 | if/when/who/how much time we can spend on it. 102 | 103 | ### Dart 2.0 104 | 105 | If we do end up declaring a Dart 2.0 that has this, there is some 106 | infrastructure in place to help. Pub already supports SDK constraints. This 107 | lets a package declare that it requires a certain version of Dart itself. If 108 | you haven't upgraded to that version of Dart yet, pub won't select that version 109 | of that package. 110 | 111 | This would help ensure users using Dart 1.x don't get broken by inadvertantly 112 | upgrading to packages that require Dart 2.0 features. 113 | 114 | Even though most existing Dart 1.x code would work in Dart 2.0, the reverse 115 | isn't true. Dart code using new syntax won't run on older VMs. 116 | 117 | To mitigate that, one of the first steps for us might be to pin down a syntax 118 | and have the VM's parser just ignore it instead of choking on it. We could do 119 | that relatively soon so that by the time that syntax is useful, more users have 120 | upgraded to a version of the VM that will at least ignore it (which is what the 121 | semantics basically are in production mode anyway). 122 | 123 | ### More next steps 124 | 125 | On our end, now, is the work to figure out what the consensus on the team is 126 | for how valuable this change is. Compared to something like async/await, 127 | actually implementing the proposal doesn't seem like that much work. Given that 128 | much of the existing Dart code is already written such that it pretends null 129 | doesn't exist, it doesn't even seem like it changes the feel of the language 130 | very much. 131 | 132 | But it does push work onto our users where they would have to add annotations 133 | in some cases. Making existing Dart users update their code is a very very 134 | large cost. New warnings would appear in previously warning-free code. 135 | 136 | So we have a lot of work to do to see how this fits into the larger Dart 137 | ecosystem. 138 | 139 | A few trailing anecdotes about non-nullable types: 140 | 141 | * When Facebook announced their [Flow type checker](http://flowtype.org/) for 142 | JS, one of its biggest bullet point features was that it did null checking. 143 | 144 | * Gilad's experience from Smalltalk was that null errors were the only type 145 | error that actually mattered. 146 | -------------------------------------------------------------------------------- /Meetings/2015-06-03 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | 6 | (Kasper couldn't make it today.) 7 | 8 | ## The proposal queue 9 | 10 | Gilad met with Lars earlier to talk about our overall proposal process. Any 11 | proposal takes real time to implement and maintain, and I we want make sure we 12 | are being strategic—will this help many Dart users significantly?—and not just 13 | tactical—is it a good feature? 14 | 15 | The current DEP process doesn't really accommodate that. We review the 16 | proposals that people care to submit and work them through the queue as quickly 17 | as we can. Proposals can make their way through the pipeline more quickly than 18 | the implementation teams can consume them. 19 | 20 | We could accept DEPs and then let them hang out for a while. But we think that 21 | leaves the language in a weird state where there are things in the spec that 22 | aren't implemented and where users don't know when they will be. 23 | 24 | This may involve occasionally tabling a good proposal. Proposals may enter a 25 | "we like this but not right now state" or something informal along those lines. 26 | 27 | The C# team picks a theme for each major release and then prioritizes language 28 | changes that fit that theme and defers ones that don't. We may want to do 29 | something similar. 30 | 31 | Having said that, let's run through what we have: 32 | 33 | ### Metadata 34 | 35 | Patrice just filed a DEP about supporting metadata annotations in more places 36 | on types. Alas, we haven't had time to look at it yet. 37 | 38 | ### [#28 Static analysis of calls on functions][28] 39 | 40 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 41 | 42 | We know what to do here and are happy with it. It's sitting waiting for Lasse 43 | to make some spec changes right now, and Gilad will offer to help out. This one 44 | should move forward. 45 | 46 | ### [#26 Full optional parameters][26] 47 | 48 | [26]: https://github.com/dart-lang/dart_enhancement_proposals/issues/26 49 | 50 | This is nice to have, but we don't feel it's something important to focus on 51 | now. 52 | 53 | ### Configuration-specific code 54 | 55 | There have been a handful of proposals here, and we (relevant people on the 56 | Dart team) spent a bunch of time during the Summit discussing it. 57 | 58 | I (Bob) am on the hook for fleshing out my [half-baked strawman][extern] since 59 | it seems to pretty promising. I haven't had time to work on it lately since 60 | I've been trying to get the [formatter][] working better, but I'll try to carve 61 | out some time. If I can't, I'll at least find someone who can. I don't want to 62 | be slowing things down. 63 | 64 | [formatter]: https://github.com/dart-lang/dart_style/tree/rules 65 | [extern]: https://github.com/munificent/dep-external-libraries 66 | 67 | Lars and lots of other people feel solving this problem is really important. 68 | 69 | ### [Generic methods][generic methods] 70 | 71 | [generic methods]: https://github.com/leafpetersen/dep-generic-methods 72 | 73 | Gilad is near finishing a draft spec for this. It includes a couple of choice 74 | points for different ways it could go. The plan is for Gilad to meet with Leaf 75 | periodically and see how the draft looks. 76 | 77 | At some point, we'll start prototyping/experimenting with an implementation. 78 | The proposal won't move forward without that. 79 | 80 | The [DDC][] folks (who are the main drivers of the proposal) and working more 81 | closely with the analyzer folks (where much of the static analysis side of the 82 | proposal will be implemented), so that's helping. 83 | 84 | [ddc]: https://github.com/dart-lang/dev_compiler 85 | [analyzer]: https://github.com/dart-lang/sdk/tree/master/pkg/analyzer 86 | 87 | There's a lot more to it than just static analysis though. It needs runtime 88 | support too, so we aren't near any kind of official DEP decision on it. 89 | 90 | ### The `const` proposals 91 | 92 | The [constant function literals][const fn] and [eliding `const`][elide] 93 | proposals are both nice to have but aren't something we want to focus on. 94 | That's OK, though, since they're both still drafts that haven't been 95 | "officially" sent to us. :) 96 | 97 | [const fn]: https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/W9zZt9T4ciA 98 | [elide]: https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/It2sBgpdIG8 99 | 100 | ### Less restricted mixins 101 | 102 | Gilad has [a proposal][mixins] to allow `super()` calls in mixins. The Polymer 103 | JS folks, among lots of others really want this, and Lars does too. 104 | 105 | [mixins]: https://github.com/gbracha/lessRestrictedMixins 106 | 107 | We'd definitely like feedback on it from users, though it's simple and clean 108 | enough that we don't expect many surprises. 109 | 110 | ## July 111 | 112 | Many of our Danish teammates go on holiday during the summer. Gilad also needs 113 | to spend a good chunk of time this summer finishing off the Dart book he is 114 | writing. 115 | 116 | So, we're going cancel DEP meetings in the month of July. Call it a summer 117 | vacation. 118 | 119 | Other proposal work can and should still proceed. File issues, iterate on 120 | proposals, start experimental implementations. But, at this point, the teams 121 | have enough work on their plates that we can take a short break and not push 122 | any more accepted proposals onto them. 123 | 124 | Lastly, I brought up the proposal that I'm most personally excited about... 125 | 126 | ## [Non-nullable types and non-nullable by default][nnbd] 127 | 128 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 129 | 130 | We think we can make this fly. We, of course, want to do an implementation and 131 | see how it feels before we commit to it, but everyone seems to be positive 132 | about it. 133 | 134 | The main remaining concern is just to see what the real-world experience of 135 | using it is. But that's a tractable problem: we can do a prototype 136 | implementation and run the experiment. 137 | 138 | We feel it's really valuable. 139 | -------------------------------------------------------------------------------- /Meetings/2015-06-10 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | 6 | Kasper is travelling for work, so this was a short meeting. 7 | 8 | ### [#28 Static analysis of calls on functions][28] 9 | 10 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 11 | 12 | Gilad hasn't had time to help out with the spec language here, but he'll try to 13 | find some time. 14 | 15 | ### [#32 Metadata for type annotations][32] 16 | 17 | [32]: https://github.com/dart-lang/dart_enhancement_proposals/issues/32 18 | 19 | Patrice recently filed this proposal. We're worried it goes a bit too far. The 20 | proposal for metadata on type *annotations* seems fine, but the section for 21 | adding metadata to other places where types can appear, like runtime type 22 | arguments, is difficult. 23 | 24 | I think Patrice put this together as a separate incremental piece towards the 25 | [non-nullable type proposal][nnbd]. By breaking the annotation syntax out into 26 | a separate proposal, it might make it easier to eventually get to non-nullable 27 | types. 28 | 29 | My feeling is that this annotation proposal is itself complex enough that it 30 | may actually slow down making progress on non-nullable types (which seem to 31 | already have a pretty good amount of traction). 32 | 33 | At the same time, we would like to have metadata in more places where type 34 | annotations can appear. One step forward might be to simplify the proposal to 35 | remove adding metadata to types that are not type annotations. 36 | 37 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 38 | 39 | ### Non-nullable types 40 | 41 | We'd like to start making concrete progress on prototyping this. The gating 42 | issue right now is nailing down a syntax for the type modifiers. Once we have 43 | that, we can start parsing (and ignoring) it. 44 | 45 | Gilad's instinct is to make `?` prefix and `!` postfix. That avoids the obvious 46 | conflicts around the ternary operator with `?` and the negation operator with 47 | `!`. 48 | 49 | My feeling is that postfix for both would be a bit more appealing to users. 50 | (For example, C#, Ceylon, and Kotlin all use postfix `?` for this.) 51 | 52 | Given that our parsers already have to do a lot of lookahead, this may be 53 | resolvable, though it's certainly nice to not have to rely on that. The right 54 | solution is to probably just ask the parser maintainers to implement one style 55 | and see how it goes. 56 | 57 | I'll follow up with Patrice and the relevant VM, analyzer, and dart2js folks 58 | and see if we can try out postfix and see if it works. 59 | 60 | If we can to a syntax that we're confident about, we can get it so that the 61 | implementations parse and ignore it. That will then let us experiment with 62 | implementing it in one system first—probably static 63 | analysis—without breaking the others. 64 | 65 | My hunch is we'll start with the static side of the proposal first because that 66 | will more directly help us answer usability questions about writing code that 67 | deals with non-nullable types. The checked mode behavior matters a lot too, but 68 | people will hit the warnings from non-nullable types statically first. 69 | 70 | ### Configuration-specific code 71 | 72 | This has been quiet for a while, mostly because of me. I'm on the hook for 73 | writing a more detailed proposal for patch files but haven't had the time. I'm 74 | finally over the hump with the formatter work I'm doing, so I should be able to 75 | carve out time for this very soon. 76 | 77 | ### [Generic methods][generic methods] 78 | 79 | [generic methods]: https://github.com/leafpetersen/dep-generic-methods 80 | 81 | Gilad has some spec language. He just needs to do a run through and get in 82 | touch with Leaf about it. 83 | 84 | ### [#34 Allowing `super()` calls in mixins][34] 85 | 86 | [34]: https://github.com/dart-lang/dart_enhancement_proposals/issues/34 87 | 88 | People pointed out a few issues around warning verbiage that Gilad fixed, but 89 | otherwise it looks good. We'll discuss it more when Kasper is back. 90 | 91 | There is an [ongoing discussion][compose] on the repo there about mixin 92 | composition, but we think that should be a separate DEP. 93 | 94 | [compose]: https://github.com/gbracha/lessRestrictedMixins/issues/2 95 | -------------------------------------------------------------------------------- /Meetings/2015-06-24 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | ### [#34 Allowing `super()` calls in mixins][34] 8 | 9 | [34]: https://github.com/dart-lang/dart_enhancement_proposals/issues/34 10 | 11 | We're there! It works in the VM. All of it works out of the box. There was a 12 | worry about how generic parameters are copied up, but it's working fine. 13 | 14 | We got some comments on the spec from Lasse and Erik, and Gilad has addressed 15 | them. 16 | 17 | Kasper talked to Lars about mixin composition. We're worried about promoting it 18 | too much since it reintroduces many of the problems of multiple inheritance. 19 | But mixin composition is separate from this proposal anyway so we're fine. 20 | 21 | The proposal is accepted! 22 | 23 | ### [#28 Static analysis of calls on functions][28] 24 | 25 | Gilad has a draft spec that Lasse has reviewed and it's all there, so we're 26 | good. This is now accepted! 27 | 28 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 29 | 30 | ### [#32 Metadata for type annotations][32] 31 | 32 | [32]: https://github.com/dart-lang/dart_enhancement_proposals/issues/32 33 | 34 | We're sympathetic to the high level notion. In principle, metadata should be 35 | allowed anywhere in the AST. That's tricky with Dart's syntax in many places, 36 | but allowing it anywhere you can put a type annotation is fine. 37 | 38 | This proposal goes farther and allows it in other places where types may appear 39 | in expressions. We don't have a mechanism to deal with that, since our APIs are 40 | designed around annotations appearing on declarations. 41 | 42 | Putting them elsewhere complicates the picture. Right now, the VM assumes it 43 | can avoid parsing metadata annotations until they are actually requested 44 | through mirrors. That's possible because we can associate the metadata with a 45 | static place in the code. If we allow metadata on *values*, that gets much more 46 | complicated. 47 | 48 | Having said that, we are interested in the part of the proposal for extending 49 | metadata around type annotations. We'd like the proposal to be scoped down a 50 | bit. 51 | 52 | After that, we're interested in taking a look with that caveat that it may not 53 | be a high priority right now so it may take a while before we get to it. We 54 | want to control the workload we throw onto the implementors. 55 | 56 | ## Configuration-specific code 57 | 58 | I'm working on revising my ["external libraries"][ext] proposal for handling 59 | configuration-specific code. I am expanding it to cover things such as the SDK 60 | extensions like the Sky team wants to do. 61 | 62 | [ext]: https://github.com/munificent/dep-external-libraries 63 | 64 | My goal is to subsume patch files and hopefully `native` keyword the 65 | implementations currently use, as get to a single system that covers our 66 | internal use cases and is clean enough to let external people like the Sky 67 | folks and people who want to do configuration-specific libraries use. 68 | 69 | One of our current challenges with SDK extensibility is that the VM has its own 70 | way of defining native behavior that isn't specified and causes grief for our 71 | other tools. But that syntax isn't actually very different from the `external` 72 | keyword in the spec. So it may be possible to either use a metadata annotation 73 | on an external function or add an optional string literal to `external`. 74 | 75 | Fletch and dart2js use metadata annotations for this. They annotate functions 76 | with a special marker annotation defined in some internal library. Some of 77 | these functions have no body and some do have bodies that are used as 78 | fallbacks. 79 | 80 | Using a string literal instead of an annotation feels a bit artificial. Since 81 | the places where this will be used will generally be in internal libraries that 82 | are in the VM's snapshot anyway, it may not be necessary to prematurely 83 | optimize by adding special syntax. 84 | 85 | Either way, the proposal covers both options. 86 | 87 | The trickiest part of the proposal is specifying how an external library is 88 | patched into the canonical library. The proposal takes a stab at that, but it's 89 | still kind of informal, likely wrong in places, and will need some iteration. 90 | 91 | I also need to work with the other stakeholders that are invested in some of 92 | the other proposals. This one may not solve all of the use cases that some of 93 | the other proposals can handle. I think this one covers most of Lasse and 94 | Erik's proposals, but may not be as expressive as Natalie and John had in mind. 95 | 96 | It will be up to me to work with them and try to get to a place where they're 97 | all happy. The nice thing about this proposal is that it has an existence proof 98 | of its utility, since it's effectively what we already use now for our core 99 | libraries. 100 | 101 | ## [Non-nullable types and non-nullable by default][nnbd] 102 | 103 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 104 | 105 | Patrice has an update to his proposal that includes a partial implementation. 106 | We haven't had time to look at it in detail yet. 107 | 108 | On our end, we have a syntax in mind for the annotations (postfix `!` and `?`). 109 | Now we need to start implementing parsing support. We'll do this behind a flag. 110 | That lets us make progress while still letting us pull it out later if it 111 | doesn't work out. 112 | 113 | ## [Null-aware operators][] 114 | 115 | [null-aware operators]: https://github.com/gbracha/nullAwareOperators 116 | 117 | The VM folks have brought to light a few corner cases as they've begun 118 | implementing this that Gilad would like to tweak the spec to address. Some 119 | cases are minor like difference between `super.?(...)` (disallowed) and 120 | `this.?(...)`. We allow the latter because `this` is just an expression even 121 | though it can never be `null`. (Well, outside of the `Null` class that is.) 122 | 123 | The interesting one is: 124 | 125 | ```dart 126 | SomeClass.?staticMethod(); 127 | ``` 128 | 129 | According to the current specification, the left-hand side of `.?` is an 130 | expression, so we treat `SomeClass` as an expression that evaluates to the type 131 | object. That isn't `null`, so then we call `staticMethod()` on it, which likely 132 | won't be found. 133 | 134 | Should we handle this specially like static calls elsewhere so that 135 | `SomeClass.?staticMethod()` looks up the method on the class when the left-hand 136 | side is a class? 137 | 138 | This problem would go away if we adopted [metaclasses]. In the meantime/absence 139 | of that, what should the behavior be? We don't think this will come up in 140 | practice much anyway. Users shouldn't do this in general, but if they *do*, the 141 | most obvious thing for users is for it work like static calls. 142 | 143 | [metaclasses]: https://github.com/dart-lang/dart_enhancement_proposals/issues/4 144 | -------------------------------------------------------------------------------- /Meetings/2015-07-01 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [gilad]: https://github.com/gbracha 5 | [kasper]: https://github.com/kasperl 6 | 7 | The team has been discussing prioritizing language changes so that we spend our 8 | time on the most urgent issues facing users. There's some worry that maybe some 9 | stuff that's already made its way into the spec but that hasn't been 10 | implemented yet isn't actually that high of a priority. 11 | 12 | The example that came up is [generalized tear-offs][tear-offs]. This was one of 13 | the first proposals and it made its way though TC52 and into the spec quickly. 14 | 15 | [tear-offs]: https://github.com/gbracha/generalizedTearOffs 16 | 17 | Now we're looking at other issues that we feel may be more worth spending 18 | engineering time on today than implementing generalized tear-offs. Part of the 19 | problem is that it seems like there aren't many people that really like the 20 | feature. If we were more excited about it, we'd probably be more eager to make 21 | the time to get it done. 22 | 23 | After some discussion, our feeling is that our only real option is to just 24 | implement the feature and move forward. It is in the spec and we are committed 25 | to fully implementing the language as specified. Of course, this is a reminder 26 | that the burden is on us to make sure everything that makes it into the spec is 27 | a feature we are really believe in. 28 | 29 | ## [External libraries][] 30 | 31 | [external libraries]: https://github.com/munificent/dep-external-libraries 32 | 33 | I finished one revision of my in-progress proposal for handling 34 | configuration-specific code and hopefully other use cases. I've gotten some 35 | good feedback but haven't had time to incorporate it yet. (I got sucked into 36 | helping out another group with some bugs.) 37 | 38 | Right now, I'm going through the external methods declared in our core 39 | libraries to get a better picture of which concrete "patching" features they 40 | need, in particular how patch files interact with library privacy. 41 | 42 | Kasper brought up that the current patch system causes a lot of complexity in 43 | dart2js so that might be a concern with the proposal. My hope is that by going 44 | through and specifying the semantics in detail, we may have a chance to 45 | simplify them a bit as well, but that depends entirely on what features we 46 | actually need for our core libraries to function. 47 | 48 | ## [Non-nullable types and non-nullable by default][nnbd] 49 | 50 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 51 | 52 | This is trucking along well. There's a ton of energy, and Patrice is putting a 53 | lot of time into it. He's revised his proposal while we're still working on 54 | digesting the original one. We may end up having to implement both to compare 55 | them. 56 | 57 | On our end, we need to start tracking the experimental implementation more 58 | tangibly. We don't intend to accept the DEP until we have a working 59 | implementation. I'll file some bugs to manage this. 60 | 61 | *(The main tracking bug is now 62 | [here](https://github.com/dart-lang/sdk/issues/23766)).* 63 | 64 | ## Implementing proposals 65 | 66 | We've gotten some feedback from the team that they aren't sure what in-progress 67 | DEPs they should be testing out and prototyping, and what they shouldn't. The 68 | official answer is that we'll let them know explicitly (by filing bugs) when a 69 | DEP is ready for an experimental implementation and we'd like them to put work 70 | into it. Until then, they shouldn't have to worry about it. 71 | 72 | (We talked a bit about making "ready for team to try" being an official state a 73 | DEP can be in, but for now we'll try to keep the flowchart simple.) 74 | 75 | Once a DEP is accepted (if not before!), we can ask the team to start 76 | implementing it. We just need to ensure it's behind an experimental flag until 77 | the feature has been approved by TC52. 78 | 79 | *(The tracking bug for super() calls in mixins is 80 | [here](https://github.com/dart-lang/sdk/issues/23770). Generalized tear-offs is 81 | [here](https://github.com/dart-lang/sdk/issues/23774).)* 82 | 83 | ## Summertime! 84 | 85 | Like we mentioned before, a combination of writing schedules and vacation means 86 | that we'll be putting the DEP meetings on hiatus until August 5th. In the 87 | meantime, we'll keep cranking on some of the other in-progress proposals like 88 | non-nullable types. 89 | -------------------------------------------------------------------------------- /Meetings/2015-08-12 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | This was our first meeting back after the July break. (Well, second, but I 9 | missed the first one.) Florian will be joining us at the meetings from now on. 10 | 11 | ### [#34 Allowing `super()` calls in mixins][34] 12 | 13 | [34]: https://github.com/dart-lang/dart_enhancement_proposals/issues/34 14 | 15 | Florian has a few concerns with the proposal as it stands. First, it prevents 16 | us from adding a warning that would be useful in many cases. 17 | 18 | #### Warning on known bad super calls 19 | 20 | Consider: 21 | 22 | ```dart 23 | abstract class Requirement { 24 | // The mixin class wants to see a 'foo' on its superclass. 25 | foo(); 26 | } 27 | 28 | // Mixin intercepts 'foo'. 29 | class Mixin extends Requirement { 30 | foo() => super.foo() + 1; // <-- 31 | } 32 | ``` 33 | 34 | Here, we know statically that that `super.foo()` call is going to call an 35 | abstract method and fail. It would be nice to change Dart to show a warning 36 | here. But, if we fix that, then this breaks the case where `Mixin` is used as a 37 | mixin: 38 | 39 | ```dart 40 | class Base implements Requirement { 41 | foo() { ... } 42 | } 43 | 44 | class Derived extends Base with Mixin {} 45 | ``` 46 | 47 | Here, that `super.foo()` call will now work because *when `Mixin` is mixed in*, 48 | its new superclass does have a concrete `foo()` method. So this proposal 49 | prevents us from adding that warning. 50 | 51 | There is also a reverse problem: 52 | 53 | ```dart 54 | abstract class Incomplete implements Requirement {} 55 | 56 | class Derived extends Incomplete with Mixin {} 57 | ``` 58 | 59 | Here, we *should* warn because the `super.foo()` call in `Mixin` will fail. 60 | 61 | #### Mixing in a class with superclasses does not mix in the superclasses 62 | 63 | This is the similar to a problem that [Siggy filed an issue for][issue]. 64 | Consider: 65 | 66 | [issue]: https://github.com/gbracha/lessRestrictedMixins/issues/2 67 | 68 | ```dart 69 | class Mixin1 { 70 | get a => 1; 71 | } 72 | 73 | class Mixin2 extends Mixin1 { 74 | get b => 2; 75 | } 76 | 77 | class Foo extends Object with Mixin2 {} 78 | ``` 79 | 80 | Users may intuit that `Foo` will inherit both `a` and `b` since they are mixing 81 | in from a class `Mixin2`, that contains both of those. However, the `extends` 82 | clause of `Mixin2` is ignored when it gets mixed in. (Informally, when you 83 | mixin a class, you only get the stuff "inside its own curlies".) 84 | 85 | #### Mixins with constructors 86 | 87 | Florian brought up the annoyance that you cannot use a class as a mixin if it 88 | declares a constructor. He sketched out an alternative proposal to address 89 | these but eventually decided he wasn't happy with that either. 90 | 91 | Kasper said the limitation on constructors is well known and that there is an 92 | eventual solution we have in mind. We haven't done it yet to keep things simple 93 | initially. Our goal is to enable as many use cases as possible while avoiding 94 | this complexity. 95 | 96 | #### Constructors and `super implements` 97 | 98 | Florian suggested that if we take my idea on Siggy's issue about `super 99 | implements` then the constructor goes away. The idea is that when you mix in a 100 | class, you ignore its constructors (and superclasses). You only mix in its 101 | methods. Any `super` calls in those methods are type-checked based on the 102 | `super implements` clause the class declares. 103 | 104 | Kasper said that if we think we will eventually do the full solution, then this 105 | problem with constructors will go away then. In that case, why worry about it 106 | now? 107 | 108 | Gilad is worried that if we try to partially solve it now, that solution may 109 | clash with what we end up wanting to do later. 110 | 111 | ### Longer meeting 112 | 113 | We talked a bit about whether we want to change or augment the time and 114 | structure of this meeting. It feels like 30 minutes isn't enough to really 115 | discuss an issue in depth. 116 | 117 | This raises a question of what the scope of these meetings is. Is it just to 118 | run through the open DEPs, see what consensus there is and update their status? 119 | Or is it also to do actual language design and discussion? 120 | 121 | Technically, it's only the former, but it seems like we could use more time for 122 | the latter. Much of the design process happens in text—mailing lists, 123 | documents, proposal repos, etc.—but actual real-time meetings have higher 124 | bandwidth and can be useful too. 125 | 126 | No real decision on this, but we'll discuss it more over email. 127 | 128 | ### Eliding `const` 129 | 130 | Lasse has a [draft proposal for not requiring `const` in many places][const]. 131 | We've talked about it a few times before but tabled it because it isn't a 132 | pressing issue. Florian brought it up because he's interested in it and to get 133 | our feelings on it. 134 | 135 | [const]: https://github.com/lrhn/dep-const 136 | 137 | My feeling is that the proposal is good, but I wonder if it will make us wish 138 | we could elide `new` as well. (Whether that in turn is a good thing or not is 139 | an open question.) 140 | 141 | Gilad still has reservations about context determining how a piece of code is 142 | interpreted. 143 | 144 | Kasper raised a concern that applying this to default values would make it hard 145 | to later support non-`const` default values. My feeling is that we shouldn't do 146 | those *anyway*—it's a notorious footgun in Python—so there's no loss there. 147 | Kasper said this is the only thing that worries him about the proposal, and 148 | noted that there is precedence for this in metadata annotations. 149 | 150 | Personally, I like how this proposal rationalizes metadata annotations in a way 151 | that makes them *not* special by not requiring `const`—they are just 152 | another `const` context. 153 | 154 | But, Gilad notes, if we go down this path, it does mean we won't be able to go 155 | back. Once we declare things as `const` contexts, we won't be able to loosen 156 | them later to allow non-`const` constructs. 157 | 158 | None of this affects the higher level question of priority. The last time Gilad 159 | discussed proposals with Lars, this was one of the ones that ended up in the 160 | "not a priority right now" bucket. We don't know if it should leave that bucket 161 | or not. 162 | 163 | Either way, Florian will talk to Lasse about default values and see what his 164 | thoughts there are. 165 | 166 | ### Making named parameters mandatory unless they have a default value 167 | 168 | Florian wanted to talk about the idea of making a named parameter required if 169 | it doesn't specify a default value. This would let a method rely on having the 170 | parameter be present (instead of having to check this in the body) while 171 | getting the readability benefits of a named parameter. For example, we 172 | encourage boolean parameters to be named, but many of those really are 173 | required. 174 | 175 | Personally, I can see the utility, but I worry that parameter lists are already 176 | so complex that it's hard to jam more features in there without ending up 177 | sacrificing usability. I don't know if I think this feature is useful *enough* 178 | to justify. 179 | 180 | Kasper suggested that in many of these places you should just define an enum 181 | instead of a boolean flag and then you don't need the parameter to be named. 182 | There are some drawbacks to that, though. It may be more tedious to define the 183 | enum than is worth. 184 | 185 | Florian's feeling is that even though this isn't a necessary feature, it 186 | addresses a pain point he runs into frequently. 187 | -------------------------------------------------------------------------------- /Meetings/2015-08-19 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## Warning on duplicate unnamed libraries 9 | 10 | **Background info:** 11 | 12 | If you omit the `library` directive in a Dart library, its name is the empty 13 | string. If you import (or export) two libraries that do this, now you have two 14 | libraries with the "same" name, which causes a warning in Dart. 15 | 16 | The duplicate library name warning exists to help you avoid cases where you 17 | reference the same library from two paths whose URLs do not canonicalize 18 | together. For example, if you have a test in your `foo` package that does: 19 | 20 | ```dart 21 | import '../lib/foo.dart'; 22 | import 'package:foo/foo.dart'; 23 | ``` 24 | 25 | You've imported `foo` twice, from different paths. That means you'll get two 26 | copies of all of their static state, you may get surprising errors in checked 27 | mode, all sorts of weird stuff. 28 | 29 | The warning tries to let you know if this happened. But, in practice, this 30 | problem is actually very rare. We have good guidelines for how to reference 31 | libraries and strong package culture, so actual collisions are rare. 32 | 33 | The name collisions that occur in practice are two totally unrelated libraries 34 | that happened to both omit their `library` directive. In this case, the warning 35 | is bogus anyway: they aren't the same library. And, of course, you can't blame 36 | someone for wanting to omit the `library` directive since it doesn't do anything 37 | particularly useful. 38 | 39 | **End background** 40 | 41 | A while back, we discussed removing the warning on duplicate library names *only 42 | for unnamed libraries*. One of the analyzer folks asked about the status of 43 | this. Gilad has discussed it previously with TC 52, and we don't think there's 44 | anything contentious about it. Gilad will tweak the spec and we'll discuss it 45 | with TC 52 in September. 46 | 47 | We spent some time discussing whether this needs to be put behind an 48 | experimental flag since it hasn't been officially approved by TC 52 yet, but 49 | it's so trivial we don't think it's worth worrying about. 50 | 51 | ## Experimental feature flags 52 | 53 | This brought the discussion to implementing not-yet-approved-by-TC-52 features 54 | behind experimental flags. Should we have a single flag for "everything we've 55 | accepted but hasn't been to TC 52 yet"? 56 | 57 | The last time we discussed this, the plan was to put each DEP behind its own 58 | feature flag. For example, allowing [`super` calls in mixins][34] should be 59 | behind a ["supermixin" flag][flag]. 60 | 61 | [34]: https://github.com/dart-lang/dart_enhancement_proposals/issues/34 62 | [flag]: https://github.com/dart-lang/sdk/issues/23770 63 | 64 | Sometimes we've been a bit lax about hiding things behind flags. Today, the 65 | main Dart implementations (the VM, dart2js, analyzer, and DDC) are all 66 | maintained by the Dart team. There aren't major independent Dart implementations 67 | in the wild yet. Given that, it's probably not worth worrying about. We don't 68 | want to be too formal about our processes. 69 | 70 | ## Reflectable 71 | 72 | Gilad has been working on his Dart book and spent some time trying out the new 73 | [Reflectable][] package. He has it featured in the chapter on reflection and in 74 | his tests he's found it works surprisingly well. 75 | 76 | [reflectable]: https://github.com/dart-lang/reflectable 77 | 78 | Right now, Reflectable's public API is a bit different from "dart:mirrors". 79 | Should we try to move the two APIs to be more compatible? That would make it 80 | easier for users to start using Reflectable by just swapping out some imports. 81 | 82 | *Editor's note: Erik clarified that it's not possible to make Reflectable 83 | perfectly follow "dart:mirrors". Reflectable requires each mirror system—each 84 | subclass of `Reflectable`—provide its own `reflect()` method where 85 | "dart:mirrors" exposes a single top-level function.* 86 | 87 | We would have to be careful because changing "dart:mirrors" could be a breaking 88 | change. We have always considered "dart:mirrors" to be unstable and subject to 89 | change. But, in practice, users are relying on it and we can't break them 90 | arbitrarily. 91 | 92 | Reflectable was designed to have an API very similar to "dart:mirrors" already 93 | so it may make sense to just try to get it closer to "dart:mirrors" instead of 94 | changing the latter. On the other hand, the places where Reflectable's API 95 | differs are generally improvements over "dart:mirrors". 96 | 97 | Florian feels that any significant change to "dart:mirrors" would have to wait 98 | until Dart 2.0. 99 | 100 | One thing Gilad likes about the Reflectable API is that it doesn't use symbols 101 | and just uses regular strings instead. He felt symbols were always a premature 102 | optimization that was confusing to users of "dart:mirrors". 103 | 104 | I asked if we have real-world customers using Reflectable yet. We have some 105 | teams that are starting to look at it. The 1.0 port of Polymer to Dart uses 106 | Reflectable. The Angular folks haven't looked at it yet because the Reflectable 107 | transformers require resolution which makes them slower than the Angular folks 108 | are comfortable with right now. 109 | 110 | Right now, Angular is a big customer of Dart and they are acutely feeling pain 111 | around reflection and metaprogramming. I would be hesitant to lock down an API 112 | for something like Reflectable until we're confident it's a good fit for users 113 | like them. 114 | 115 | ## Dart 2.0 116 | 117 | We're just starting to discuss what a potential "Dart 2.0" could mean. How big 118 | of a change would it encompass? How painful of a transition is acceptable? What 119 | do we think the resulting language would look like? 120 | 121 | Of course, we always want to minimize pain, but what is the acceptable 122 | trade-off? How much pain is worth it to get to feature X? For all of these 123 | questions, we'll get feedback from the user community to see how they feel. 124 | 125 | Very early on, we decided 2.0 would have almost no breaking changes. We would 126 | call it 2.0 officially because there may be some small breakages, but we'd do 127 | our very best to not break most programs. 128 | 129 | Since then, we've started thinking about being more ambitious. Should we 130 | consider some more fundamental changes to the language? For example, Gilad would 131 | be happy to see first-class libraries and metaclasses—features that would change 132 | the flavor of the language. 133 | 134 | What is the opportunity cost of *not* making ambitious changes like this? Today, 135 | we feel that as a language we're OK, but we're not super-attractive. It could be 136 | that we're too conservative and aren't getting the full benefits of owning our 137 | own language. 138 | 139 | But, doing ambitious changes like this takes real, significant engineering time. 140 | It's a huge resource commitment to plan, design, experiment, implement, test, 141 | and ship large language changes. It would take us as well as many others on the 142 | team. Are we willing to do that? Kasper is leaning towards "yes" but it's not at 143 | all decided. 144 | 145 | If we do decide to put that time into it, we better solve some fundamental 146 | issues and get some real value out of it. 147 | 148 | Florian points out that many fundamental changes are actually less breaking than 149 | "minor changes". In many cases, you can statically see the new feature, so tools 150 | can help you fix your code. But, say, renaming the `add()` method on List would 151 | be virtually impossible. It may end up that some of these fundamental issues may 152 | be easier than library "clean-ups". 153 | 154 | Kasper says doing this may make the language more "foreign" but may help us 155 | stand out from the crowd more. I believe we may end up with something that 156 | doesn't feel more foreign. Right now, we're straddling the line between 157 | dynamically typed languages and statically typed ones. If we move in either 158 | direction, we may pull out of the uncanny valley towards either a more familiar 159 | Smalltalk/JS/Ruby dynamic style or a C++/Java/C# static style. 160 | 161 | Obviously, we still have lots more to discuss here. 162 | 163 | ## Resources 164 | 165 | The `Resource` API we are close to shipping doesn't seem to meet all of the use 166 | cases we need it to. There's an alternative suggestion to add a dedicated syntax 167 | for referring to a resource from code. This would us do things like reference a 168 | resource at a path relative to the source file. On the other hand, it implies 169 | that all resources used by a program have to be statically embedded in the code. 170 | 171 | In practice, I don't think this will be useful. Users will want to write 172 | middleware layers, resource managers and helper functions to work with resources 173 | generically. Those won't be possible if you have to list all of your resources 174 | statically in your code. 175 | 176 | Florian says the currently-designed `Resource` class has similar problems 177 | already. If we don't have many users who need this right now, maybe we should 178 | drop this from the release. From talking to Natalie, the impression I get is 179 | that it's not ready yet, so I'm in favor of postponing it until we have 180 | something better. 181 | 182 | Kasper points out that the pressing problems were trying to solve with resources 183 | are still there and pushing off the Resource API leaves them unsolved. It's 184 | still appealing to solve at least some of the problems if not all of them. Lars 185 | wants the ability to detect at least some of the resources at compile time so 186 | that they can be bundled up with the snapshot. 187 | 188 | I look at it more as postponing it than killing it. Once we ship something in 189 | the SDK, it *must* be stable so we cause ourselves a lot of pain if we ship 190 | something where we aren't sure it's a great solution for our problems. One 191 | option is to mark it experimental. That will let us get it out there to get 192 | feedback while still letting us make changes. 193 | 194 | Of course breaking even an experimental feature may still break users, which 195 | can scare people away. It may be better to not ship at all. 196 | 197 | ## Iteration and velocity 198 | 199 | Kasper thinks there's a larger lesson we need to learn here. It feels like we're 200 | somehow rushing features and then when it reaches implementation things break 201 | down. Then we get feedback and we have a hard time applying it. It feels like 202 | that part of our process is broken. Our track record is not fantastic. 203 | 204 | Gilad feels we have an "excess of velocity". We can't easily pull back a change, 205 | so we should invest more time in design before we ship it. A good idea is to 206 | implement things before announcing and standardizing them. We tend to rush 207 | things to TC 52. 208 | 209 | I agree. It's not that we need a slower waterfall, it's that we need more 210 | iteration, experimentation and data gathering before a design is locked down. It 211 | doesn't matter how slow you go. If you don't get good feedback, you aren't going 212 | to do good design. 213 | 214 | Florian notes that we have a very large corpus of internal code where we can 215 | make sweeping changes. We should take advantage of this and try out features 216 | there and prove our designs before we ship them. 217 | 218 | Now that we're on Git, it's easy for us to develop on feature branches, which 219 | gives us a natural path to merge or reject experimental implementations. 220 | -------------------------------------------------------------------------------- /Meetings/2015-08-26 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## Proposal updates 9 | 10 | Here's the proposals that are candidates for going into Dart 1.13: 11 | 12 | ### [Assert messages][assert] 13 | 14 | Seth has [a proposal][assert] to add an optional message parameter to 15 | `assert()` statements. It hasn't been formally submitted to the committee yet. 16 | 17 | [assert]: https://github.com/sethladd/dep_assert_with_optional_message/blob/master/proposal.md 18 | 19 | There are a couple of minor questions like: 20 | 21 | * If the condition evaluates to `true`, do we still evaluate the message 22 | argument? 23 | 24 | * Does the message have to be a string or can it be any object (and we 25 | implicitly call `toString()` on it)? Gilad thinks it should be a string to 26 | get some kind of type-checking. 27 | 28 | Florian brought up an alternative to the proposal: put a Dartdoc comment before 29 | the assertion and have tooling able to find that and show it. I said you can do 30 | that now manually based on the stack trace. The nice thing about messages is you 31 | can do interpolation at runtime and have a more precise message: "The value 32 | should be less than 11, but you passed 42.". 33 | 34 | Overall, though, we think the proposal is fine and it would be nice to move it 35 | forward. The next step (and the process we want to use in general going forward) 36 | is to do an experimental implementation. Then, if that goes well, we'll move 37 | towards accepting it. 38 | 39 | I've filed a [tracking bug](https://github.com/dart-lang/sdk/issues/24213). 40 | 41 | ### [#28 Static analysis of calls on functions][28] 42 | 43 | [28]: https://github.com/dart-lang/dart_enhancement_proposals/issues/28 44 | 45 | This is accepted, and we think the implementations were already doing the right 46 | thing. We want to be able to officially declare it in Dart 1.13, so Florian will 47 | check and make sure the implementations are all doing the right thing. 48 | 49 | Gilad has discussed it with TC 52, and we expect they will agree with it too. 50 | 51 | ### [#3 Generalized tear-offs][3] 52 | 53 | [3]: https://github.com/dart-lang/dart_enhancement_proposals/issues/3 54 | 55 | This has been approved by TC 52. The VM has shipped them and is the only 56 | implementation that has. There's been no priority yet for implementing it the 57 | analyzer and dart2js. Florian will talk to the relevant people and make sure 58 | something happens. 59 | 60 | The proposal went through because Lars really likes it. It's been voted on, so 61 | we need to implement it or do something about it. We can't leave it in limbo. 62 | 63 | If we don't think it's the best thing for Dart users and the Dart project, then 64 | changing it is probably a 2.0 thing. 65 | 66 | ### [#34 Less restricted mixins][34] 67 | 68 | [34]: https://github.com/dart-lang/dart_enhancement_proposals/issues/34 69 | 70 | The DEP has been accepted but hasn't been to TC 52 yet. We don't expect there 71 | to be any changes, so we should just finish implementing it. The VM already 72 | has. Florian will follow up with the relevant people. 73 | 74 | ## Changing the meeting 75 | 76 | Florian proposed we broaden the scope of this meeting to be more proactive about 77 | driving the evolution of the language. That also means we'll make it longer: one 78 | hour. 79 | 80 | In that time, we'll go over proposals but also actively take on subjects that we 81 | think can make Dart better. In other words, more like the old "language 82 | meetings" we used to have. 83 | 84 | ## Dart 2.0 85 | 86 | In particular, as we start talking about Dart 2.0, we need a form for longer, 87 | more open-ended meetings. As a starting point, in the next meeting, Florian 88 | would like to discuss what things we think could or should be removed from Dart 89 | in 2.0. 90 | 91 | We need to start doing these discussions and stop tiptoeing around Dart 2.0 if 92 | we want to get there in a reasonable amount of time. We may have disagreements, 93 | but we need to work those out. We need to find the common ground among our group 94 | to see if there is a single "Dart" that we are all excited about. 95 | 96 | ## Nullable types 97 | 98 | Florian started a discussion about whether we think a nullable type should be 99 | assignable to a non-nullable one. In other words, can you *implicitly* "cast" 100 | the nullability away. 101 | 102 | Personally, I don't it should be allowed. Assigning a value that may be null to 103 | a variable that never expects one is exactly the point in my code where I want 104 | the type checker to draw my attention, is the likely place where bugs may occur. 105 | 106 | But, playing Devil's advocate, this is incompatible with our regular notion of 107 | assignability. Dart allows implicit downcasts in general based on the philosophy 108 | that the assignment *may* often work (the variable often is the right subclass 109 | even if we only statically knows it's a superclass). Likewise, a nullable-typed 110 | variable often does have a non-null value, so an assignment to a non-nullable 111 | type will often work. 112 | 113 | I agree that disallowing assignment from nullable to non-nullable types is 114 | inconsistent with implicit downcasting, but I also don't like implicit 115 | downcasting. I'd rather get rid of that than make non-nullable assignments 116 | looser. 117 | 118 | Of course, this would be a 2.0 kind of change. 119 | 120 | ## Soundness 121 | 122 | This leads to a larger discussion about soundness. Gilad has always liked 123 | optional typing, but never felt that the optional type system itself should be 124 | unsound. There is a point in the design space where you have an optional type 125 | system but where you do use it, you are sound. 126 | 127 | The type system already has an escape hatch: it's optional. If you've opted *in* 128 | to using it, we don't need more holes *within* that. 129 | 130 | Generics is another pain point with unsoundness. Making those sound would be 131 | very difficult. Florian feels that making generics invariant would be too 132 | difficult to work with. 133 | 134 | Gilad discussed with Philip Wadler one point in the design space: Make generics 135 | invariant and whenever you need polymorphism, make a generic method. Gilad 136 | feels that may also be painful. But, personally, I worked in C# 2.0 for several 137 | years writing lots of generic code in exactly this way and always found it 138 | pretty pleasant. 139 | 140 | Gilad thinks invariant generics might be worth reconsidering if we can provide 141 | a much better tooling experience. It's not helpful if the user just gets an 142 | error when they try to pass a `List` to something that expects to read 143 | from a `List`. But, say when you wrote a method that took a list and only 144 | read from it the tool would pre-emptively suggest you make the method generic 145 | with a `T extends num` type parameter" and offerred to fix it for you on the 146 | spot, that could be a lot better. 147 | 148 | ## Splitting the spec 149 | 150 | Florian brought up the position that the type system could be pulled completely 151 | out of the core Dart specification. As long as the syntax lets you write all of 152 | the annotations you need, the (or a) type system could be a separate tooling 153 | feature. For example, DDC has its own set of type rules that it enforces. 154 | 155 | As long as Dart is expressive enough to let you write a program that *could* be 156 | soundly checked, we could leave it up to separate tools to define that. 157 | 158 | My feeling is that the set of people who can design and implement a sound type 159 | system is pretty small. If we're going to do half the work to ensure the 160 | annotations are expressive enough, we're probably the best people to just design 161 | and implement the whole thing. 162 | 163 | Gilad brings up that we still could be the ones to provide it. Even then, 164 | having a layer of separation between the core language and the type system 165 | gives us more freedom. In the same way that it's easier to hack on pub because 166 | it isn't fully-specified by the language, it would be easier to iterate on the 167 | type checking rules if they aren't baked into the language spec. 168 | 169 | This suggests we would split the spec in two: the dynamic and static behavior. 170 | The two would evolve at their own rate. The former likely more slowly than the 171 | latter. 172 | 173 | Checked mode makes this much more complicated. Once you have a type system at 174 | runtime, you have some obligation to be coherent with your static one. My 175 | feeling is that if you have a sound type system, checked mode may not be as 176 | valuable anyway. 177 | 178 | It's still useful given that data can move in and out of dynamically typed code, 179 | so type errors may appear at runtime that can't be caught statically. But, if 180 | the type system is sound, and you stay within fully typed code, you know there 181 | won't be type errors at runtime. Maybe checked mode doesn't add much value 182 | beyond that. Florian believes it is still important for catching bugs. 183 | 184 | Gilad brought up that we could recast the idea of checked mode into something 185 | that feels less like a type system and more like a flexible assertion system. 186 | They wouldn't have hard-wired assumptions about the full Dart type system. It 187 | would be nice to be able to only run parts of your program in checked mode. If 188 | we look at these as assertions that can be injected, and if we avoid ratholes 189 | like generics in checked mode, there may be a good story. 190 | 191 | Generics in checked mode is what led us to reified generics, which in turn 192 | causes other complications for us with the type system and things like type 193 | inference. 194 | 195 | Personally, I've never found once reified generics useful in Dart, though 196 | Florian does feel they catch bugs in checked mode. 197 | 198 | *Erik notes that you could also have a variant where generics are reified in 199 | checked mode but not in production mode, and `is` and `as` cannot rely on 200 | them.* 201 | 202 | I do worry that separating out the static type rules from the dynamic semantics 203 | may cause us problems down the road. If we want to make Dart really successful 204 | on small-power, small-memory embedded devices, that naturally leads towards 205 | value types. Those may be harder to design if the static type annotations are 206 | very separate from the runtime behavior. (In other languages, declaring a 207 | variable as `int` dictates both its static type, and its storage 208 | representation.) 209 | 210 | Gilad feels this won't be a problem, but we ran out of time to discuss it 211 | further. 212 | -------------------------------------------------------------------------------- /Meetings/2015-09-09 Language Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## [Generic methods][generic methods] 9 | 10 | [generic methods]: https://github.com/leafpetersen/dep-generic-methods 11 | 12 | Florian spent some time prototyping what the Dart core libraries would look like 13 | if we added generic methods. The standard methods like `Iterable.map()` and 14 | `Iterable.fold()` look like you expect, are easy, and just work. 15 | 16 | It's hairier in the [Zone][] API. That API is highly generic and has lots of 17 | higher-order functions. For something like `registerCallback()`, if you want the 18 | function you pass to it to be fully typed, you end up needing a lot of type 19 | parameters on the method itself. It's feasible, but it may be a lot of work. 20 | 21 | [zone]: https://api.dartlang.org/1.12.1/dart-async/Zone-class.html 22 | 23 | That API also brings up questions about whether generic methods are first class. 24 | Can you have a first-class function that you can invoke with type arguments? We 25 | discussed this before at the Dart Summit and other places, but I'm not sure if 26 | we've reached consensus yet. 27 | 28 | The [ZoneSpecification][] class is configured by the user by passing in a bunch 29 | of callbacks. Those callbacks may need to be generic to fully support how the 30 | Zone API wants to call it. This might be an extreme, uncommon case that we don't 31 | have to address. 32 | 33 | [ZoneSpecification]: https://api.dartlang.org/1.12.1/dart-async/ZoneSpecification-class.html 34 | 35 | Florian offered to write up some more details on how the experiment is going so 36 | far to share with us. I asked him to push it out as a branch on the SDK repo. 37 | 38 | ## [Non-nullable types][nnbd] 39 | 40 | [nnbd]: https://github.com/dart-lang/dart_enhancement_proposals/issues/30 41 | 42 | Florian has started prototyping non-nullable type support in dart2js. He added 43 | some temporary syntax for it to the parser. Then started implementing the 44 | propagation so that nullable and non-nullable types flow through the system and 45 | report errors. 46 | 47 | For example, if you do `o.x` without having checked that `o` is not null, its 48 | type annotation must be non-nullable. Likewise, if a function returns `null`, 49 | it's return type must be nullable. Then dart2js propagates outwards from there 50 | and sees what kind of clashes occur. 51 | 52 | He thinks it's going to go well, but he's a little afraid of being able to make 53 | it work for generic types. He only just started working on this, but he's hoping 54 | to get it far enough to see what kinds of changes we'd need to make to dart2js 55 | and our core libraries to get them happy with non-nullable types. He thinks it's 56 | even possible to get checked mode for non-nullable types working in dart2js. 57 | 58 | When this is further along, he'll write something up about how the experiment 59 | went. 60 | 61 | ## Meeting format 62 | 63 | We've started having really important discussions about what the next major step 64 | for Dart may look like. But it doesn't seem like the DEP meeting is the best 65 | venue for that. It may set confusing expectations that "Dart 2.0" is nearer or 66 | more concrete than it really is. 67 | 68 | We are considering fundamental changes, and we want to have these discussions in 69 | the open, but we want people to understand the tentative context around them. 70 | The DEP meetings, which are pretty concrete and near-term make that confusing. 71 | 72 | So we've decided to split the meetings up. This meeting will go back to being a 73 | short, focused meeting to discuss the current ongoing proposals. 74 | 75 | For larger language evolution discussions, we haven't figured out the right 76 | forum yet—difficult when you are open source and your team is spread 77 | across a few time zones—but we will. 78 | 79 | ## DEP status 80 | 81 | The list of DEPs could stand to have some of their statuses cleaned up. They are 82 | basically in one of a few buckets: 83 | 84 | * A while back, Lars and Gilad met to discuss which proposals Lars feels are a 85 | high priority. For the proposals that didn't make that list, we think they 86 | would be nice to have, but we don't want to place to heavy of an 87 | implementation burden on the team all at once. Proposals in the "nice to have" 88 | bucket are basically on ice for now until we free up more bandwidth. 89 | 90 | * A few proposals are "awaiting revision". It basically means we've given the 91 | author feedback and we're content to leave the ball in their court until they 92 | want to get back to us and push for some action. 93 | 94 | * A couple of proposals like generic methods are being worked on by people on 95 | the team. 96 | 97 | * Then there are a few proposals around configuration-specific code... 98 | 99 | ## Configuration-specific code 100 | 101 | Last week, I met with most of the stakeholders around this. Our discussions 102 | lately have mostly coalesced around a Florian's "interface library" proposal 103 | with some refinement based on [Erik's proposal][variation]. Florian's is itself 104 | a variation of [Lasse's original proposal][configured imports] around this. 105 | 106 | What I'm doing now is writing a standalone document that pulls together all of 107 | the various bits and pieces we've talked about in other docs and email threads. 108 | I'll send that out as soon as I can and then hopefully that will be the proposal 109 | we do an experimental implementation of. 110 | 111 | It feels to me like the discussions are tapering to something concrete. 112 | 113 | [configured imports]: https://github.com/lrhn/dep-configured-imports 114 | [variation]: https://github.com/eernstg/dep-configured-imports 115 | 116 | ## Package map and resources 117 | 118 | There's a library issue being discussed about package maps. Should the core 119 | libraries give you a way to locate a package inside the program? It only makes 120 | sense on the standalone VM, so this would be a "dart:io" API. 121 | 122 | There are some open issues around this because the VM currently loads the 123 | package map lazily, but it's being discussed. We need to figure out soon because 124 | it interacts with the Resource API which is also in-progress. 125 | -------------------------------------------------------------------------------- /Meetings/2015-09-16 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## Configuration-specific code 9 | 10 | Based on my discussions last week, I wrote up [a proposal for interface 11 | libraries][interface libraries] and sent that around to the analyzer folks and 12 | the other stakeholders. It's ready for more feedback, so I'll file it as a DEP 13 | and Gilad will take a look. There's still one section that needs filling in, and 14 | I'm hoping to get some help with that. But otherwise, I think it's ready to be a 15 | DEP. 16 | 17 | [interface libraries]: https://github.com/munificent/dep-interface-libraries 18 | 19 | The runtime semantics are *very* simple. You can practically implement it at 20 | parse time. The static checking is optional and can then be layered on top of 21 | that. 22 | 23 | We'll plan to discuss the proposal in this meeting next week. 24 | 25 | ## [Assert messages][37] 26 | 27 | [37]: https://github.com/dart-lang/dart_enhancement_proposals/issues/37 28 | 29 | Lasse was working on implementing this in dart2js but ran into an issue, so he's 30 | planning to hand that off to the dart2js team. 31 | 32 | ## DEP process 33 | 34 | I suggested that I should update the [docs and flowchart][docs] to add an 35 | explicit "doing experimental implementation" stage a proposal goes through 36 | before being accepted. That lines up with the process we've verbally agreed to. 37 | I just need to write it down. 38 | 39 | [docs]: https://github.com/dart-lang/dart_enhancement_proposals 40 | 41 | ## [`const` functions][const] 42 | 43 | [const]: https://github.com/yjbanov/dart-const-functions 44 | 45 | There's been a lot of discussion about Yegor's proposal for adding the ability 46 | to define functions that can be invoked in const expressions. 47 | 48 | It's not a submitted DEP yet, but we brought it up to see if we want to be 49 | involved in proactively guiding it. 50 | 51 | Personally, I'm not a fan of `const` in general, so it's hard for me to get 52 | excited about a proposal that builds on it. I feel that `const` doesn't provide 53 | much value for the sizable complexity it adds. Making it more powerful would, I 54 | think, wouldn't add enough value to really dig it out of that whole. 55 | 56 | I think making `const` more powerful is a step along a slippery slope towards 57 | ultimately having a separate language that's as expressive and complex as Dart 58 | itself. 59 | 60 | For possibly the first time in history, Gilad and I are in complete agreement. 61 | Let the record note it. 62 | 63 | I want to take a step back and look at what problems the Angular folks are 64 | solving. I think it's natural for Angular and pretty much any framework to need 65 | to let users add extra bits of declarative data to various constructs and then 66 | be able to access and use that data at runtime. 67 | 68 | Metadata annotations *seem* like the natural place to do that, but then you run 69 | into the `const` limitation. That limitation makes some sense for when you want 70 | to process metadata annotations at *compile time*. Thinks like transformers that 71 | consume metadata annotations need to be able see what their values are without 72 | running arbitrary Dart code. 73 | 74 | But if you're using metadata annotations to embed data in the application that 75 | really is part of program and is being used at runtime, there's no need to limit 76 | it to `const`. You're running Dart code at that point, so arbitrary expressions 77 | could be allowed. 78 | 79 | One possible solution would be to simply allow arbitrary expressions in metadata 80 | annotations. Some *tools*, like Angular's transformer, that consumes annotations 81 | at compile time may place restrictions on what kinds of expressions are allowed 82 | in the annotations *it* cares about. But the language itself wouldn't 83 | premptively limit *all* annotations in that way. 84 | 85 | Or we could add some other separate kind of metadata annotation that is 86 | lazily-evaluated at runtime. 87 | 88 | These may play nice with [Reflectable][] it what we need is effectively a big 89 | map of data keyed by some declaration. In some cases—classes and 90 | functions—the declaration is already first class. 91 | 92 | [reflectable]: https://github.com/dart-lang/reflectable 93 | 94 | I'm not sure if the `const` function proposal is a good solution, but it does, I 95 | think highlight a real problem in Dart where it isn't very framework friendly. 96 | For now, our plan is to see how the proposal matures and try to get a better 97 | understanding of what use cases and problems it addresses. 98 | -------------------------------------------------------------------------------- /Meetings/2015-09-30 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## Leads meeting 9 | 10 | Last week, a bunch of the leads on the Dart team met to strategize or whatever 11 | it is leads do. One interesting outcome of it is that we're going to give each 12 | of the teams that owns a Dart implementation—the VM, dart4web, and 13 | Fletch—more leeway in what they support. They have the freedom to ship 14 | something that works for their platform but may not be supported on the other 15 | ones. 16 | 17 | For example, the Flutter folks, and the Dart VM team supporting them, are going 18 | to do what they need to make their product successful. We've seen the same thing 19 | in dart4web and Fletch. 20 | 21 | In many ways, this is what we've always done. For example, there was never any 22 | real plan to support big integers in dart2js even though the language specifies 23 | it. Now we don't have to feel as guilty about that. 24 | 25 | This makes our job on the DEP committee harder. We're focused on the core 26 | language that is shared across those implementations and we want to maximize the 27 | size of that. There is still a ton of benefit to being compatible across 28 | implementations and being able to reliably share code. 29 | 30 | Our task is to improve the overall language in ways that all of the 31 | implementation teams are excited about. In some ways, they're our customer. 32 | Meanwhile, they may come up with something that makes sense for them but not the 33 | other implementations. We can try to generalize it to something useful across 34 | the whole system, or help them, or let them do it on their own. 35 | 36 | The boundary of what is truly shared and compatible across all implementations 37 | is fuzzier now. It's kind of alarming, but it's probably a good thing. Dart is 38 | mainly a client-side language. When you run on the user's hardware, you need to 39 | have a high affinity to it to work well and perform efficiently. 40 | 41 | Languages that succeed there tend to be chameleonic and adjust their colors a 42 | bit based on what they are running on. This is why C has undefined behavior, and 43 | why Java server, GWT, and Android all treat Java a little differently. The 44 | platforms are divergent, so it makes sense for the language to be a little 45 | divergent too. 46 | 47 | Having said that, we really get the value of being able to share code *across* 48 | platforms, so our goal is to minimize fragmentation while still letting the 49 | implementation teams be successful. 50 | 51 | ## [Config-specific code][40] 52 | 53 | [40]: https://github.com/dart-lang/dart_enhancement_proposals/issues/40 54 | 55 | We have agreement on what we want to try to implement, but we haven't started 56 | yet. Florian has some time, so he's going to get started. I want to as well, but 57 | I've been busy so haven't had a chance yet. He'll let me know what he starts on 58 | so we don't step on each other's toes. 59 | 60 | ## [Assert message param][37] 61 | 62 | [37]: https://github.com/dart-lang/dart_enhancement_proposals/issues/37 63 | 64 | There's an open question. Does the parameter have to be a string, or can it be 65 | any object that is coerced to a string? 66 | 67 | A while back, I emailed the DEP folks suggesting it should allow any object by 68 | comparison to other language features: 69 | 70 | * It's consistent with `print()`, which allows any type. 71 | * It's consistent with `throw`, where the VM calls `toString()` on the object 72 | and shows the result when displaying the stack trace. 73 | * It's roughly consistent with `if` and `while` which allow non-boolean types in 74 | production mode. 75 | * It's consistent with `await`, which allows non-Future arguments and implicitly 76 | converts them to futures. 77 | * It's consistent with interpolation which calls `toString()` on the 78 | interpolated value. 79 | 80 | Gilad didn't find that convincing and prefers it to be a string, though he 81 | doesn't care that much either way. 82 | 83 | Florian suggested instead of coercing immediately, just store the original 84 | object in the AssertionError. When you display the error, it would get 85 | `toString()` called on it then. That would let you inspect the actual object in 86 | a debugger. 87 | 88 | Kasper said this was good and general, but how much actual value does it add? If 89 | you want to have an error with an interesting object, why not throw an 90 | exception? 91 | 92 | Insisting on a string may lead to better tooling. We could maybe do better 93 | auto-complete for that parameter if it know it's a string. If it's really 94 | uncommon for it to be any other kind of object, guiding the user can be helpful. 95 | 96 | Florian thinks allowing any object is simpler to spec. 97 | 98 | Gilad said most people he talked to do seem to prefer it to allow any object, 99 | even though he thinks that's more likely to cause mistakes than yield real 100 | benefit. But he would be happy to change it if that's what the committee 101 | decides. 102 | 103 | Most of us don't seem to have a strong opinion one way or the other, so Florian 104 | made the deciding call to stick with a string. 105 | 106 | ## [Improved default constructors][ctors] 107 | 108 | [ctors]: https://groups.google.com/a/dartlang.org/forum/#!topic/core-dev/cQZlx90c7z0 109 | 110 | Lasse had an idea for extending the default constructor. Instead of no 111 | parameters, it would get a named parameter for each field in the class. That 112 | would let you define a class like: 113 | 114 | ```dart 115 | class C { 116 | int foo; 117 | final int bar; 118 | int baz = 42; 119 | } 120 | ``` 121 | 122 | Which you could then construct like: 123 | 124 | ```dart 125 | new C(foo: 42, bar: 10) 126 | ``` 127 | 128 | It's a neat idea. It became more interesting lately because I've been reviewing 129 | a lot of internal Dart code in Google. I see a ton of code that creates objects 130 | like this: 131 | 132 | ```dart 133 | new Address() 134 | ..street = (new StreetAddress() 135 | ..number = 123 136 | ..street = (new Street() 137 | ..name = "Main" 138 | ..kind = "St.")) 139 | ..city = "Springville" 140 | ..state = "Illinois"; 141 | ``` 142 | 143 | I don't have a lot of context when doing these reviews, so I'm not sure exactly 144 | why they do this. Sometimes it's because these types are coming from 145 | [protobufs][], but I see this even in hand-authored sites. 146 | 147 | [protobufs]: https://github.com/dart-lang/dart-protobuf 148 | 149 | Aside from the verbosity and general strangeness, note that this means all of 150 | these fields have to be public and mutable. 151 | 152 | I wonder if we had Lasse's suggestion, if people would use that instead: 153 | 154 | ```dart 155 | new Address( 156 | street: new StreetAddress( 157 | number: 123, 158 | street: new Street(name: "Main", kind: "St.")), 159 | city: "Springville", 160 | state: "Illinois"); 161 | ``` 162 | 163 | Gilad doesn't like constructors to begin with, so he's not keen on adding more 164 | to them. They are already very complex and even adding something like this may 165 | not prevent this kind of problem. 166 | 167 | I offered to sketch out a proposal if the committee is interested, after I free 168 | up some time. But first, I want to do some more investigation about the code 169 | that uses lots of cascades to get a better picture of why they're doing it that 170 | way. 171 | 172 | It's true that constructors are already very complex (initialization lists, 173 | const, redirecting, factory, initializing formals, etc.), so we don't want to 174 | add anything else unless we know it actually helps. 175 | -------------------------------------------------------------------------------- /Meetings/2015-10-14 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | 7 | ## Dealing with lazy compile errors 8 | 9 | **Context:** 10 | 11 | Natalie is working on the [test][] package. Obviously, it's important for a test 12 | runner to be robust in the face of errors and failures in the tests. In 13 | particular, it's important to reliably run the tear down code, even when an 14 | unexpected error occurs in a test. 15 | 16 | [test]: https://pub.dartlang.org/packages/test 17 | 18 | For the most part, it does that by catching any exception that gets thrown, but 19 | there is one case it currently can't handle. 20 | 21 | The Dart VM reports syntax and compile errors lazily, only when the method or 22 | function containing the error is first called. 23 | 24 | Here's a Dart program: 25 | 26 | ```dart 27 | badFunction() { 28 | look at this crazy syntax error! 29 | } 30 | 31 | main() { 32 | print("ok"); 33 | } 34 | ``` 35 | 36 | You might expect this to not run, but it actually prints "ok" and completes just 37 | fine. The spec deliberately allows this because it improves startup time. The VM 38 | can defer parsing, validating and compiling a chunk of code until the first time 39 | it's actually used. 40 | 41 | However, when a syntax error *is* found this way, it cannot be handled. If this 42 | code is running in an isolate, the isolate is immediately aborted. This means 43 | the test runner can't catch this and run the tear down code before the isolate 44 | dies. 45 | 46 | She'd like to be able to handle this more robustly. Her request is to be able to 47 | catch syntax errors. 48 | 49 | **End context** 50 | 51 | Gilad's feeling is that if a test has a compile error, the user should notice 52 | that (probably using the analyzer) and just not run the test at all. 53 | 54 | Florian doesn't feel aborting the program or isolate is a good answer. We can 55 | live with it, but it isn't the best solution. 56 | 57 | I think the current behavior is wrong. If it's possible to execute some code in 58 | a file in order to set up some state, you should be able to handle an error in 59 | that same file in order to be able to restore the original state. 60 | 61 | Gilad doesn't want to add more complexity to the language to handle this. Dart 62 | is already in unfamiliar territory because of the way it lazily reports compile 63 | errors. Being able to *catch* compile errors at runtime would put us in 64 | uncharted waters. 65 | 66 | It's a fairly rare issue. And it's easily avoided by just not running your test 67 | if there's a syntax error in it, which the analyzer will be happy to tell you. 68 | 69 | I do think the current behavior is weird. Most users aren't aware of it, and 70 | those that are tend to be unpleasantly surprised. It reminds of me of C++ 71 | templates where you can have all manner of syntax errors in the template and you 72 | won't know until you try to instantiate it. I don't think anyone is thrilled by 73 | that feature. 74 | 75 | I think the VM supports being run in "compile all" mode where it eagerly 76 | compiles everything before starting. Maybe we could add that to the Isolate API 77 | so you could start an isolate in that mode? 78 | 79 | Florian would rather not expose a new API users have to worry about. He wants to 80 | see how costly it would be to see if we can just get the VM to report syntax 81 | errors eagerly (without necessarily *compiling* eagerly) and not run any code if 82 | there is a syntax error. 83 | 84 | Gilad and I think that's sensible too. 85 | 86 | Over the long term, we may be able to get away from lazy compile error 87 | reporting. It was important when we were aiming to get the Dart VM in a browser. 88 | There, startup time is critical and you're running Dart directly from source. 89 | Now that most Dart implementations have an explicit compile step anyway, it may 90 | not be important to be able to defer reporting syntax errors. 91 | 92 | Florian will talk to the VM folks about it. 93 | 94 | ## [Config-specific code][40] 95 | 96 | [40]: https://github.com/dart-lang/dart_enhancement_proposals/issues/40 97 | 98 | Florian has implemented the dynamic behavior in the VM and dart2js. He got the 99 | OK from both teams to land those patches behind an experimental flag. 100 | 101 | The remaining work on those platforms is the predefined environment constants. 102 | He has a patch for them for dart2js but nothing for the VM yet. Before he works 103 | on this, he'd like to change the proposal around them. 104 | 105 | Right now, the proposal has a hard-coded list of "dart:" libraries and the 106 | constants that get defined for them. Instead, he thinks the behavior should be 107 | that each 'dart:' library an implementation provides gets a constant whose value 108 | is `true`. This way, the proposal is open-ended to new Dart libraries in custom 109 | embedders, like, "dart:flutter". 110 | 111 | I'm all for that too. We'll tweak the proposal. 112 | 113 | Now the big missing piece is analyzer support. Before we can even try it out, we 114 | at least need phase 0 support—it needs to be able to parse the syntax 115 | without freaking out. 116 | 117 | Florian would like it to support phase 1—checking public 118 | functions—before we start getting users to try it out. He wants to start 119 | out with the most restrictive behavior so we don't commit to things we don't 120 | need. 121 | 122 | It's not clear to me that phase 1 has to be the most restrictive behavior. 123 | Without actually checking public types for compatibility, we have two options if 124 | a public type appears in an interface library: do nothing or warn. Doing nothing 125 | means "Yeah, you can do this dynamically, but the static tooling can't help you 126 | make sure you're doing it right." Always warning says, "This isn't even 127 | supported." 128 | 129 | Personally, I think it should not warn. I think it's OK for the static analysis 130 | to not cover all things users can express dynamically. I don't think we'll get 131 | good end user feedback that configured types are important if the tools try to 132 | scare them away from even trying them. 133 | 134 | Florian and Gilad feel it's safer to start conservatively. If the warning is 135 | getting in their ways, users can let us know and we'll consider that a signal 136 | that configured types are desired. 137 | -------------------------------------------------------------------------------- /Meetings/2015-10-21 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][], [Kasper][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | [kasper]: https://github.com/kasperl 7 | 8 | ## [Config-specific code][40] 9 | 10 | [40]: https://github.com/dart-lang/dart_enhancement_proposals/issues/40 11 | 12 | Most of the meeting was discussing this proposal. In particular, how to handle 13 | public types in configuration specific libraries. 14 | 15 | There isn't consensus on how important it is to be able to configure types. 16 | Supporting this is necessary if you want to be able extend a 17 | configuration-specific class at runtime. The driving example is the `Element` 18 | class in `dart:html`. 19 | 20 | The dart4web team would like to be able to write a platform-independent wrapper 21 | around the DOM that works both on the server (using html5lib) and in the 22 | browser. You could imagine something like: 23 | 24 | ```dart 25 | // html.dart 26 | export 'html_interfaces.dart' 27 | if (dart.library.html) 'dart:html' 28 | if (dart.library.io) 'html5lib_impl.dart'; 29 | ``` 30 | 31 | So, if you import "html.dart" and extend the `Element` class it gives you, your 32 | subclass will extend the real honest-to-God DOM `Element` class when you run it 33 | in Dartium. Likewise, when you compile it with dart2js, it will know you are 34 | extending the real `Element` and not a wrapper. 35 | 36 | In the meeting, we couldn't reach consensus on how important it is to support 37 | this and similar use cases. 38 | 39 | Supporting it requires being able to statically check types for compatibility. 40 | In other words, we want the analyzer to be able to reliably tell you if the 41 | `Element` class in `dart:html` is a reliable substitute for the one in 42 | `html_interfaces.dart`. Likewise the one in `html5lib_impl.dart`. 43 | 44 | The rules for doing that compatibility checking haven't been precisely defined 45 | yet. We don't have consensus on how complex those are either. Florian describes 46 | the amount of work as "huge". I think it's fairly simple. 47 | 48 | Given that we don't know how important *or* how difficult to support this use 49 | case is, the question is what do we do in the interim? The proposal is broken 50 | into phases specifically because of this. The idea is that during the 51 | experiment, we will initially implement phase 1 of static analysis which only 52 | checks top-level functions and variables for compability. 53 | 54 | What happens when a user does declare a public type in a config-specific library 55 | then? I think we should just let the user try that even though they won't get 56 | the assistance of static checking. The others in the meeting strongly feel this 57 | should always be a static warning. When/if phase 2 is implemented, the warning 58 | would be replaced with more fine-grained checking of types. 59 | 60 | We've decided to implement phase 1's static checking and warn if a public type 61 | appears in a config-specific library. After that, users can start trying out the 62 | feature. Meanwhile, we'll work with the analyzer folks to see how difficult it 63 | would be to implement phase 2. 64 | 65 | ## [Assert message param][37] 66 | 67 | [37]: https://github.com/dart-lang/dart_enhancement_proposals/issues/37 68 | 69 | After deciding that the assert message should be a string, we got feedback from 70 | the team that they wanted to allow arbitrary objects. So, we've agreed to loosen 71 | this and let the argument be anything. 72 | -------------------------------------------------------------------------------- /Meetings/2015-11-11 DEP Committee Meeting.md: -------------------------------------------------------------------------------- 1 | Attendees: [Bob][], [Florian][], [Gilad][]. 2 | 3 | [bob]: https://github.com/munificent 4 | [florian]: https://github.com/floitschG 5 | [gilad]: https://github.com/gbracha 6 | 7 | ## [Assert message param][37] 8 | 9 | [37]: https://github.com/dart-lang/dart_enhancement_proposals/issues/37 10 | 11 | Strangely enough, we are still discussing the dark corners of this. The open 12 | question now is what happens if an exception is thrown when evaluated the 13 | message argument. 14 | 15 | Consider this (completely contrived) example: 16 | 17 | ```dart 18 | assert(shouldBeTrue, "This will fail: $doesNotExist"); 19 | ``` 20 | 21 | Should the user get: 22 | 23 | 1. An `AssertionError` describing the `NoSuchMethodError`. 24 | 2. The `NoSuchMethoderror` itself. 25 | 3. An `AssertionError` for the failed assertion ignoring the fact that the 26 | message threw. 27 | 28 | My feeling, which I think I've at least convinced most people of, is that we 29 | should do #2. If there is a bug in your assertion message code, you'd really 30 | like to fix that bug. It's no fun having bugs inside the code you use to detect 31 | other bugs! 32 | 33 | If we make the fail look like the assertion itself has failed (which itself 34 | implies some *other* bug), then the user may not realize the *message* failed 35 | too. In that case, they may fix the code causing the assertion to fail. Once 36 | they do that, the code for the message no longer gets evaluated and they won't 37 | know there is still a bug lurking in there. 38 | 39 | I think it's better to draw attention to the message failure so that users fix 40 | that *first*. 41 | 42 | One way to get this behavior is by specifying `assert()` in terms of an explicit 43 | constructor call to `AssertionError`. We don't think this is a good idea because 44 | it limits how the VM can report assertion failures. Right now, it doesn't just 45 | desugar `assert(condition, message)` to something like: 46 | 47 | ```dart 48 | if (!condition) throw new AssertionError(message); 49 | ``` 50 | 51 | Instead, it adds some extra data to the AssertionError object like the source 52 | text of the condition. That stuff is helpful for a user. Specifying that the VM 53 | *must* call a certain constructor prevents that. 54 | 55 | Most of the discussion around this has happened on a [code review][] that 56 | Florian didn't see, so he'll catch up on that and follow up on it. 57 | 58 | [code review]: https://codereview.chromium.org/1324933002/ 59 | 60 | ## Handling syntax errors 61 | 62 | We've [discussed this before][syntax]. 63 | 64 | [syntax]: https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-10-28%20DEP%20Committee%20Meeting.md#handling-syntax-errors 65 | 66 | We feel that if the body of a function has a syntax error, it would be good if 67 | it was possible for a user to be able to handle that at runtime. This lines up 68 | well with the idea of a live editing experience where users can patch and 69 | replace methods on the fly while the system is running. 70 | 71 | You could imagine treating it like any function whose body contains a syntax 72 | error has its body implicitly replaced with `throw new SyntaxError(...)`, which 73 | is pretty straightforward. But, after talking to the VM team, it seems like 74 | there is a bunch of complexity hiding in the problem. There are cases where it 75 | can get weird. 76 | 77 | Likewise, there are syntax errors that are likely not recoverable. Things like 78 | errors at the level of a class declaration or at the top level. 79 | 80 | Florian is going to spend more time talking to the VM team about it. 81 | 82 | ## [Config-specific code][40] 83 | 84 | [40]: https://github.com/dart-lang/dart_enhancement_proposals/issues/40 85 | 86 | Florian has a patch for the VM, but the VM team doesn't want to land it without 87 | analyzer support in place. Florian started a patch for the static analysis then 88 | discovered the analyzer folks are already working on it themselves. 89 | 90 | They have support for the syntax now. The static checking hasn't been 91 | implemented yet. We could land this without the static checking and hide the 92 | feature behind a flag, but Gilad and Florian would rather have some checking in 93 | place first. 94 | 95 | The analyzer folks have been thinking pretty deeply about the static checking. I 96 | get emails every few days asking clarifying questions about increasingly deeper 97 | and darker corners of the semantics. 98 | 99 | They are definitely finding interesting consequences, but so far nothing too 100 | alarming has shown up as far as I know. 101 | 102 | They have some process challenges around how to land these changes. Because the 103 | analyzer is used both by internal tools *and* has a public library API, "behind 104 | a flag" isn't very well-defined. If they change the AST classes, that's part of 105 | analyzer's public API. 106 | 107 | ## "Non-controversial" changes 108 | 109 | Florian brought up a few micro-scale language changes that he's interested in 110 | and that he thinks are fairly non-controversial (though maybe not *all* of them 111 | are). 112 | 113 | * Allowing `_` inside number literals. Other languages allow this to group 114 | digits, like `1_000_000_000`. Easy to add and kind of nice. 115 | 116 | * `0b` for binary number literals. 117 | 118 | * Incomplete surrogates in string literals. You can manually build a string 119 | that contains these, but there's no literal form for them. 120 | 121 | Given that some implementations are talking about changing their string 122 | encoding and given how string encoding issues always seem to be a rathole, 123 | this may be controversial. 124 | 125 | * Removing the need for nested `const` qualifiers. This one already has [a 126 | proposal][const]. 127 | 128 | [const]: https://github.com/lrhn/dep-const/blob/master/proposal.md 129 | 130 | We spent a little time discussing scope and priority of language changes. The 131 | vibe is that in the DEP process we don't seem able to make changes that are 132 | large in scope. But the kind of small-scale changes we can make are 133 | correspondingly small in *impact*. 134 | 135 | Even very small changes seem to have a surprisingly large implementation cost, 136 | so it's not clear if that's what we want to spend resources on right now. Would, 137 | for example, we rather have the team implementing for binary 138 | literals—including parser support in the analyzer, dart2js, VM, syntax 139 | highlighters, tests, specification, etc.—or should we spend that time 140 | doing things like making analyzer faster or adding VM features the Flutter folks 141 | want? 142 | 143 | ## Assertions in const constructors 144 | 145 | Florian doesn't have a proposal, but users have asked for the ability to have a 146 | body in const constructors only to contain asserts so you can do some validation 147 | of the state of a new const object. 148 | 149 | From talking to users, his impression is that users are reaching for const 150 | because they really want immutable objects. So maybe the real problem we should 151 | be tackling is explicitly supporting objects that are deeply immutable after 152 | construction. 153 | 154 | This would, for example, make it easier to be able to send these kinds of 155 | objects across isolates. 156 | 157 | We ran out of time, but this is something we'd like to talk about more. 158 | 159 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## DEPRECATED 2 | 3 | **While we are still very much actively evolving the language, we are no longer 4 | using the DEP process for managing these changes.** 5 | 6 | For current design and evolution of the Dart language, please see the 7 | [Dart language repo](https://github.com/dart-lang/language). 8 | -------------------------------------------------------------------------------- /Walkthrough.md: -------------------------------------------------------------------------------- 1 | Let's say Kate has an idea improve the Dart platform. Here's how she goes about 2 | it. From here on out, "she" refers to Kate, and "we" refers to the DEP 3 | committee. 4 | 5 | Here's the short version of the steps she takes: 6 | 7 | 1. Kate starts an informal discussion on the [`core-dev@dartlang.org`][core-dev] 8 | mailing list. 9 | 2. She creates a new repo for her DEP containing a file named `proposal.md` 10 | based on our [template][]. 11 | 3. When she's ready for us to see it, she [files an issue][issue] pointing to a 12 | commit in her repo, asking us to take a look. 13 | 4. We take that issue and label it "draft". 14 | 5. When we meet, we check out her proposal and give feedback. She responds and 15 | revises her proposal. 16 | 6. If we get to a point where we are happy with the proposal, we change its 17 | status to "experimental" and the team begins implementing it behind a flag. 18 | 7. Based on how that goes, we refine the proposal, or possibly close it if 19 | it doesn't work out in practice. 20 | 8. If we're happy with it, we create a new directory under 21 | [`Accepted/`][accepted] in our repo with the full text of her proposal. We 22 | close the bug as ["accepted"][accepted issues]. 23 | 9. At this point, the proposal goes to TC52. If they are happy with it, the 24 | experimental flag is removed and the feature is shipped. 25 | 26 | [core-dev]: https://groups.google.com/a/dartlang.org/forum/#!forum/core-dev 27 | [template]: https://github.com/dart-lang/dart_enhancement_proposals/blob/master/DEP%20Template.md 28 | [issue]: https://github.com/dart-lang/dart_enhancement_proposals/issues 29 | [accepted]: https://github.com/dart-lang/dart_enhancement_proposals/tree/master/Accepted 30 | [accepted issues]: https://github.com/dart-lang/dart_enhancement_proposals/issues?q=label%3Aaccepted+ 31 | 32 | Here's the longer story: 33 | 34 | ## Conception 35 | 36 | Kate keeps running into some problem in her Dart code. She asks around on the 37 | [main mailing list][misc] and [StackOverflow][] but no one seems to have a good 38 | solution or workaround. Eventually, she has an idea for a solution that 39 | requires a change to Dart itself. The next thing she does is send an email to 40 | [`core-dev@dartlang.org`][core-dev]. 41 | 42 | [misc]: https://groups.google.com/a/dartlang.org/forum/#!forum/misc 43 | [stackoverflow]: http://stackoverflow.com/tags/dart 44 | 45 | She discusses it with the folks there—people both on the Dart team and off. 46 | Many ideas will die here, which is good. Lots of problems already have good 47 | solutions or maybe the solution is just infeasible. If people seem to think the 48 | idea has merit and is worth pursuing, she goes to the next step: 49 | 50 | ## Writing the Proposal 51 | 52 | She **creates a new Git repo**, likely on GitHub, but all that matters is that 53 | it's somewhere public. Initially the repo will probably just contain one file: 54 | 55 | proposal.md # DEP doc. 56 | 57 | The proposal is a [Markdown][] document that she creates by copying [our 58 | template][template] and filling it in. 59 | 60 | [markdown]: http://en.wikipedia.org/wiki/Markdown 61 | 62 | That's all that's *required* at this point, but she is more than welcome to add 63 | other files: 64 | 65 | spec.tex # Language spec changes, if any. 66 | test/ # Language tests. 67 | prototype/ # Implementation. 68 | example/ # Examples of using the proposal. 69 | 70 | Whatever supporting artifacts she thinks are helpful. The repo is basically a 71 | little product in itself. She can collaborate with other people, talk about it, 72 | take pull requests and issues, whatever she wants. It's a living, breathing 73 | workspace. 74 | 75 | She probably *won't* have actual proposed spec language changes, at least not 76 | initially. The set of people who can write that kind of stuff correctly is very 77 | small. Fortunately, we have a few on staff, so as Kate's proposal reaches 78 | maturity, we can help fill this in. Of course, she's welcome to work on it too. 79 | It's her proposal, after all. 80 | 81 | When she decides the proposal document and other artifacts are ready for the 82 | committee to see, she **gets our attention by filing an [issue][]** on the 83 | [dart_enhancement_proposals repo][dep repo]. 84 | 85 | [dep repo]: https://github.com/dart-lang/dart_enhancement_proposals 86 | 87 | The text of the issue should be: 88 | 89 | This is the tracking issue for DEP: ****. 90 | 91 | The proposal lives [here][repo]. 92 | 93 | *Note: This issue is a tracking bug for the status of the proposal. To 94 | comment on the proposal itself, file issues on its [repo][], not here.* 95 | 96 | [repo]: 97 | 98 | She fills in the `` and ` parts. This **tracking 99 | issue** stays open as long as her DEP is in progress. It's the canonical 100 | identifier for her DEP. Its [label][] defines the current status of the DEP. 101 | 102 | [label]: https://github.com/dart-lang/dart_enhancement_proposals/labels 103 | 104 | ## A Living Draft 105 | 106 | We (probably [Bob][]) see that issue has come in. We label it "draft". At this 107 | point, it's a live DEP. From here on out, when the committee meets, it will be 108 | on our agenda. 109 | 110 | [bob]: https://github.com/munificent 111 | 112 | In a timely manner, we **review the proposal** and the other stuff in the repo. 113 | We **provide feedback to her** by filing issues in her proposal's repo, sending 114 | her email, or in the [DEP meeting notes][]. 115 | 116 | [dep meeting notes]: https://github.com/dart-lang/dart_enhancement_proposals/tree/master/Meetings 117 | 118 | In general, filing issues is the most reliable way for us or others to give her 119 | feedback. It lets her respond to them individually. It means other people also 120 | contribute and comment on the issues as well. She can label them, triage them, 121 | fix them, etc. 122 | 123 | We can contribute in other ways too. We may send her pull requests if we want 124 | to actively chip in. Meanwhile, she controls what actually lands so she doesn't 125 | have to worry about us hijacking her proposal. 126 | 127 | Other people can send her patches and pull requests. She can make commits to 128 | her repo use branches, whatever she wants while she's revising things. This is 129 | *much* more flexible than something like a single pull request for the lifetime 130 | of the proposal. 131 | 132 | When she and her contributors make changes, they let us know so we check up on 133 | her proposal the next time we meet. Eventually, if things go well, we get to a 134 | point where we don't have any more feedback to give but are still excited about 135 | the proposal. We've learned all we can from a text proposal. It's time to get 136 | real. 137 | 138 | ## Implementing the Proposal 139 | 140 | We mark the tracking issue as "experimental". This is the signal to the Dart 141 | team and other contributors that we can begin putting resources into 142 | implementing the proposal. It will be behind an **experimental flag** since it 143 | is not a supported part of the Dart platform (yet), but will be a real, working 144 | implementation. Any user who opts in to that flag will be able to try it out and 145 | give us feedback. 146 | 147 | We learn a lot during this. As the implementors run into ambiguous corners of 148 | the text or other issues, they give her feedback. She tightens and revises the 149 | proposal, and (likely with help from the team) produces final spec language for 150 | it. 151 | 152 | Once we've got a complete spec, solid working code, and real user feedback, we 153 | can tell if this is an overall asset to the Dart platform or not. If it goes 154 | well, we are ready to commit to it. 155 | 156 | ## Acceptance 157 | 158 | At this point we: 159 | 160 | * Label the tracking bug "accepted" and close it. 161 | * Copy the contents of her repo into 162 | [dart_enhancement_proposals][dep repo] under 163 | [`Accepted//...`][accepted]. 164 | 165 | Now, the proposal has exited the DEP process and moves into the more official 166 | Ecma standardization process. If we've done our job well, the proposal will 167 | satisfy the committee and will get ratified pretty much as-is. 168 | 169 | However, the TC52 group always has final say over what makes it into the 170 | standard and there is a chance the proposal will be modified or possibly even 171 | rejected. Our goal with the DEP process is to make sure the proposals we deliver 172 | are so great that they slide right in and everyone is happy. 173 | 174 | If TC52 gives it the thumbs up, we remove the experimental flag and the feature 175 | has now shipped and is officially supported. 176 | -------------------------------------------------------------------------------- /codereview.settings: -------------------------------------------------------------------------------- 1 | # This file is used by gcl to get repository specific information. 2 | CODE_REVIEW_SERVER: https://chromereviews.googleplex.com 3 | VIEW_VC: https://github.com/dart-lang/dart_enhancement_proposals/commit/ 4 | CC_LIST: dart-enhancement-committee+reviews@google.com 5 | --------------------------------------------------------------------------------