From d74cdf78e1cb73ae91ff9e47a5de0c2de8c9a44d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marvin=20L=C3=B6bel?= Date: Tue, 2 Feb 2016 15:18:43 +0100 Subject: [PATCH] Raise an unresolved question about specialization --- text/0000-conservative-impl-trait.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/text/0000-conservative-impl-trait.md b/text/0000-conservative-impl-trait.md index bfe7a7fc5c5..5cc848a9ddb 100644 --- a/text/0000-conservative-impl-trait.md +++ b/text/0000-conservative-impl-trait.md @@ -176,7 +176,7 @@ item-level API, but has been deemed worth it for the following reasons: declare `Send`/`Sync`-ability, and not extending this problem to abstract return types is desireable. In practice, most uses of this feature would have to add explicit bounds for OIBITS - if they want to be maximally usable. + if they wanted to be maximally usable. - Low real change, since the situation already somewhat exists on structs with private fields: - In both cases, a change to the private implementation might change whether a OIBIT is implemented or not. @@ -374,4 +374,12 @@ types private to a function body, for example a iterator adapter containing a cl > What parts of the design are still TBD? -None for the core feature proposed here, but many for possible extensions as elaborated on in detailed design. +- What happens if you specialize a function with an abstract return type, + and differ in whether the return type implements an OIBIT or not? + - It would mean that specialization choice + has to flow back into typechecking. + - It seems sound, but would mean that different input type combinations + of such a function could cause different OIBIT behavior independent + of the input type parameters themself. + - Which would not necessarily be an issue, since the actual type could not + be observed from the outside anyway.