Update status of KEEPs #53, #23, #13, #47, #19

Kotlin · Dec 4, 2016 · b831649 · b831649
1 parent a270383
commit b831649
Show file tree

Hide file tree

Showing 5 changed files with 12 additions and 8 deletions.
diff --git a/proposals/stdlib/abstract-collections.md b/proposals/stdlib/abstract-collections.md
@@ -2,7 +2,7 @@
 
 * **Type**: Standard Library API proposal
 * **Author**: Ilya Gorbunov
-* **Status**: Under consideration
+* **Status**: Implemented
 * **Prototype**: Implemented
 * **Discussion**: [KEEP-53](https://github.com/Kotlin/KEEP/issues/53)
 

diff --git a/proposals/stdlib/group-and-fold.md b/proposals/stdlib/group-and-fold.md
@@ -206,20 +206,20 @@ The operation returns `Map<K, R>`, where `K` is the type of the key and `R` is t
         There is a risk of confusing `groupingBy` and `groupBy`.
 
     * `count`/`sumBy` can be misinterpreted as operations on the whole collection, rather on each group.
-        * resolution: `countEach`, `sumEachBy`
+        * **resolution**: `countEach`, `sumEachBy`
 
     * `Grouping` is often referenced in docs as "grouping source", so maybe we should name it `GroupingSource`?
 
 2. Which general forms of `fold`/`reduce`/`aggregate` should we provide?
     * Method count is increased
-        * resolution: since there's a single receiver for all operations, the impact on method count is not that big.
+        * **resolution**: since there's a single receiver for all operations, the impact on method count is not that big.
     * Having them as overloads hurts completion during gradual typing.
 3. Should we provide `To`-overloads (like `groupByTo`) with a mutable map as a target parameter?
-    * resolution: there are no easy alternatives to achieve the same results without these overloads,
+    * **resolution**: there are no easy alternatives to achieve the same results without these overloads,
      so we should provide them.
      
 4. Having primitive fold accumulators stored in a map introduces a lot of boxing.
-    * resolution: provide optimized implementations of `countEach` and `sumEachBy`. 
+    * **resolution**: provide optimized implementations of `countEach` and `sumEachBy`. 
     Note that, there's no such optimization for `countEachTo` and `sumEachByTo`.
 
 5. Should we provide `sumEachByLong` and `sumEachByDouble` operations, 

diff --git a/proposals/stdlib/map-copying.md b/proposals/stdlib/map-copying.md
@@ -2,7 +2,7 @@
 
 * **Type**: Standard Library API proposal
 * **Author**: Ilya Gorbunov
-* **Status**: Discussed
+* **Status**: Implemented
 * **Prototype**: Implemented
 * **Target tickets**: [KT-9108](https://youtrack.jetbrains.com/issue/KT-9108)
 * **Discussion**: [KEEP-13](https://github.com/Kotlin/KEEP/issues/13)

diff --git a/proposals/stdlib/on-each.md b/proposals/stdlib/on-each.md
@@ -2,7 +2,7 @@
 
 * **Type**: Standard Library API proposal
 * **Author**: Christian Brüggemann
-* **Status**: Discussed
+* **Status**: Implemented
 * **Prototype**: Implemented
 * **Related issues**: [KT-8220](https://youtrack.jetbrains.com/issue/KT-8220)
 * **Discussion**: [KEEP-47](https://github.com/Kotlin/KEEP/issues/47)

diff --git a/proposals/stdlib/string-to-number.md b/proposals/stdlib/string-to-number.md
@@ -3,7 +3,7 @@
 * **Type**: Standard Library API proposal
 * **Author**: Daniil Vodopian
 * **Contributors**: Ilya Gorbunov
-* **Status**: Submitted
+* **Status**: Implemented
 * **Prototype**: Implemented
 * **Related issues**: [KT-7930](https://youtrack.jetbrains.com/issue/KT-7930)
 * **Indirectly related issues**: [KT-8286](https://youtrack.jetbrains.com/issue/KT-8286), [KT-9374](https://youtrack.jetbrains.com/issue/KT-9374)
@@ -90,10 +90,14 @@ The reference implementation is provided in the pull request [PR #839](https://g
     * `String.tryToInt()`
     * `String.tryParseInt()`
 * Difference between JDK6 and JDK8 in allowing the leading `+` sign.
+    * This is acceptable difference.
 * Returning nullable number introduces boxing which may be wasteful.
 * Investigate how to introduce `base`/`radix` parameter for string-to-integral type conversion functions [KT-8286](https://youtrack.jetbrains.com/issue/KT-8286):
     * Should it be another parameter or an overload with a different name (like `toIntBase(16)`)?
+        - it will be an additional parameter `radix`
     * Should it be a single overload with an optional parameter or two overloads?
+        - given that a method with default arguments gets compiled to two methods in bytecode, two overloads with no default arguments 
+        will result in the same number of methods, but providing more convenient way to call them from Java.
 
 ## Future advancements