Don Syme
Don Syme
> I suspect that a collection type without its own (lightweight!) literal syntax would end up being used only when performance concerns begin to surface, and it would be largely...
I'm fine with someone fixing this. I regard it as a glitch in the language definition (but it's in there and thus by design) which could be improved.
> But there can be some gaps, and it'd probably ease current interop patterns with ASP.NET Core. In the preview bits I played with for some reason I couldn't just...
Things to consider * Would we allow literals ``"abc"`` * Would we allow literals ``@"abc"`` * Would we allow literals ``"""abc..."""`` * Would "+" be supported, operating on two strings...
> I think the underlying concern is to get type safety and identical runtime representation (in the example, it is still a string, without any extra overhead) and newtype does...
I'm personally still not a huge fan of this feature, though I probably will end up approving it. I like the clarity that, when using byrefs, there is a need...
I suspect there are cases where this could be a breaking change, at least we'd need to be very careful An example is where active patterns are in scope, but...
I like this suggestion. cc @KathleenDollard
Marking this as approved-in-principle. Since the design is simple by all means proceed straight to an RFC and PR :)
It feels like for consistency we have to use `printn`. It feels wrong to have all of `println`, `printfn` and `WriteLine` in the experience. But let's consider.