WIP: Notes

Author: Immo Landwerth

accepted/2021/preview-features/preview-features.md

@@ -418,3 +418,75 @@ Originally I used the term *experimental* but we decided to change it to
   <50%, e.g. in `runtimelabs`
 * Overall, the goal is draw more people in and motivate them to try the
   features. The term *preview* seems more helpful than *experimental*.
+
+----------------------
+
+## Notes
+
+* Should we support multiple feature flags _as well_?
+    - If a feature is runtime only, we use environment variables today quite
+      successfully. Maybe we should only differentiate between features that
+      impact the binary on disk (compiler, APIs) vs. process lifetime. For
+      runtime features we often do perf work and we want to know whether it
+      helps or not.
+    - For runtime libraries, we generally don't believe a library can or should
+      declare a hard dependency on runtime only features, because they are often
+      perf tweaks.
+    - We don't believe we can change names of feature flags because historically
+      not been able to rename them.
+    - Maybe documenting them on docs.microsoft.com as unsupported is good
+      enough.
+    - We generally don't use `AppContext` switches for preview features, but we
+      use it for more than just compat switches, e.g. trimming.
+* Should we use `LangVersion` as the main switch?
+    - For language features, it's well established that people set this
+      property.
+    - The `LangVersion` property doesn't have quite the right name and it would
+      now cause transitivity requirements.
+    - Using this property might not work well for VB and F#
+    - The biggest counter argument is that the compiler can be in stable version
+      but the TFM you're targeting is not.
+    - If we use a separate property, then this means the user could have preview
+      features off, but language is in preview mode. This would result in
+      configuration where the user can use runtime features that are in preview.
+      One option is to use `RuntimeFeatures` and mark the field as
+      `[RequiresPreviewFeatures]` that causes the compiler to enforce the
+      containing assembly/type/member to be marked as
+      `[RequiresPreviewFeatures]` as well. Aleksey believes this check needs to
+      be in-place regardless of number of checks. Another option is to simply
+      fail the build as an invalid configuration.
+* Analyzer vs Compiler feature
+* VS releases
+* Multiple TFMs
+
+## From Jeremy
+
+For the compiler versioning (and other languages) vs "API impacted platform
+features" (or whatever you want to call them):
+
+* Maybe it's OK if C#-2025 can't compile certain syntaxes against .NET 6 with
+  experimental support .. e.g. we changed something in how generic math works
+  and they've decided "its been a couple releases, time to move on".
+* Conversely, even if the compiler supports that combination, if we changed
+  generic math then there may be a runtime break on assemblies compiled against
+  net6-preview vs net7, so an explicit experimental gesture is still a
+  requirement
+
+The three scenarios I commented on in chat may also be useful in addition to
+those points:
+
+* Preview language feature with experimental API: string8 str = 8"Hello, World";
+* Should generate the "I used experimental API, my callers need to accept that"
+  attribute.
+* Stable language syntax with experimental API
+    - `Utf8String str = new Utf8String("Hello, World");`
+* Should generate the attribute
+* Preview language features that would work on net5 or older: things like
+  autoprops or records or required partial members.
+* The attribute doesn't seem needed here.  Why should this necessarily dead-end
+  your NuGet package?
+
+(To be clear: I don't think we need to make anything be smart enough that
+attribute generation is tied to actual usage, if making the gesture emits it
+even when you don't need it that's OK (except when it isn't) -- I'm just
+pointing out they're two different axes)