Efficient params and string formatting

[jaredpar]

This proposal is being discussed at LDM on 3/4/2019.

[jaredpar]

FYI: i did not forget about this. I'm actually trying to track down my notes. Verdict though is it's not a good solution for C#.

[bdukes]

Proposal looks wonderful, just a couple of typos, etc.

[jaredpar]

JaredPar can't spell part 2

[tannergooding]

nit: The CoreFX reads weird. Maybe just use CoreFX

[tannergooding]

Are you going to be putting the Variant proposal up on CoreFX as well?

[jaredpar]

@JeremyKuhne owns that. Pretty sure it's one corefxlab already.

[Logerfo]

can't stop laughing about the typos they just keep coming

[jaredpar]

Don't worry they won't stop.

[CyrusNajmabadi]

if we're going to go to this, wouldit be oke to also allow going to ICollection/IList/IReadOnlyList at teh same time (effectively, all the types that T[] already implements)? It feels like it would be a prime time to just roll this in since we're working in this area.

[tannergooding]

Why would you need to support the others, since they all implement IEnumerable<T>? Generally speaking, types that implement things like ICollection or IList can also efficiently implement their iterators (and do in the case of most CoreFX types).

[tannergooding]

I think that the currently proposed types cover most of the scenarios. That is, Span<T>/ROSpan<T> make sense since they provide allocation-less calls (and declare the immutability of the input data) and IEnumerable<T> allows easier interop with LINQ (it avoids the need to realize a query).

[CyrusNajmabadi]

Why would you need to support the others, since they all implement IEnumerable?

Because i want to expose this api to users:

public static void Foo(params IReadOnlyList<T> whatever) { }

Allowing people to just pass their existing list to me. Or, they can pass raw values, and it will be an array, an that doesn't need to be converted into an IReadOnlyList since it already is one.

[jaredpar]

I'll add it to the open issues. We didn't cover it in LDM.

[CyrusNajmabadi]

Thanks so much! I would understand if this didn't happen. However, it's been one of those language niggles for ages. If it's cheap, this would be nice to have :) It would def clean up a few of my apis.

Note: @tannergooding and i discussed this on Gitter. It is definitely a strange thing that the language has baked in understanding that an array has an implicit reference conversion to IList and its ilk. And, yet, for 'params' i must specify only a T[] type. It seems like it would be pretty simple to just relax that to "anything an array has reference implicit conversion to".

[CyrusNajmabadi]

could you expand on this further?

[jaredpar]

The later sections go into a few of the possible scenarios here around stack allocation.

[CyrusNajmabadi]

is there more info on Variant and how it works? A link, perhaps, to the CoreFx side of tings?

[jaredpar]

I added a link to the PR that has the initial Variant code spit and that has a bit of conversation. I don't think there is an official design doc though. Will let @JeremyKuhne comment on that.

dotnet/corefxlab#2595

[CyrusNajmabadi]

would you need a ReadOnlySpan of hte string portions of hte interpolated string, along with the ReadOnlySPan of interpolation values? Or am i misunderstanding how this would be used? For example, if you have:

$"foo{bar}baz"

how is the ValueFormattableString created? I would prefer a form that gave me "foo" and "bar" in a ReadOnlySpan, and something that gave me the Variant for bar in a ReadOnlySpan.

[CyrusNajmabadi]

this approach seems unfortunate... because won't i now have to figure out how to break "hello {0}" up, even thouh the language already did that for me? I'm coming from this from a JS/TS perspective where this is the natural way this data is packaged up and passed along to template processors.

[jaredpar]

This is the approach that interpolated strings use today. The goal of this proposal is to make the existing process more efficient vs. opening up the door for text templating. That was brought up though in LDM and we're going to look into it a bit though. If you have some pointers to the JS / TS similar features I'd like to read up on them.

[CyrusNajmabadi]

This is the approach that interpolated strings use today

That's fair. Though it would be nice if both forms could be supported. Having to have clients manually parse strings is a PITA. JS/TS info on template strings is here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

Importantly:

function template(strings, ...keys) {
  return (function(...values) {
    var dict = values[values.length - 1] || {};
    var result = [strings[0]];
    keys.forEach(function(key, i) {
      var value = Number.isInteger(key) ? values[key] : dict[key];
      result.push(value, strings[i + 1]);
    });
    return result.join('');
  });
}

This is how one could write a function that accepts an interpolated string. From TypeScript's perspective, the signature is:

function template(literals: TemplateStringsArray, ...placeholders: string[]) {

TmplateStringsArray is also super interesting. It is typed as:

interface TemplateStringsArray extends ReadonlyArray<string> {
    readonly raw: ReadonlyArray<string>;
}

Meaning, it actually represents two arrays of strings. For example if i had:

whatever `this is a \t { template } \t string literal`;

Then the first arg passed to 'whatever' would look like this:

{
     [ "this is a \t ", " \t string literal"]
     raw: [ "this is a \\t ", " \\t string literal" ]
}

So JS gives both the original raw strings and the interpreted language strings. I'm not asking for that myself, but at least having the separate strings makes it so much easier to do things.

[CyrusNajmabadi]

It would be great if the Language/Compiler codified this (similer to how some languages carve out __ names as being reserved for them). If the language drew a line and said "we may change behavior for new types introduced in the System... space, and you should not be adding anything there yourself" then this gives both a reasonable path to add a lot of stuff in the future, while also being able to point users at some struct guidelines in case they do bad stuff.

[bdukes]

Leaving System. namespaces available for general use can allow third party libraries to implement features on older versions of the framework that aren't officially supported for that particular feature. But having a compile warning may be appropriate.

[jaredpar]

We've essentially drawn the line on types defined under System.. We're still pretty careful about introducing breaking changes here but if we feel we can improve things and it's a type under System. we'll accetp a level of breaking changes to do it.

[CyrusNajmabadi]

Great. I wasn't certain if htat was something official, or more informal. I was basically saying that it would be nice if really just stated it officially.

[CyrusNajmabadi]

Was the '3' brought about by an sort of analysis of existing codebases? i'd be really curious what the 'tail' looks like her.e i.e. if 3 gets us 95% of the way, but 4 gets us to 99.9%, that would be interesting to know.

[jaredpar]

@JeremyKuhne can comment on that.

[bdukes]

Just a couple more 😉

[yaakov-h]

Sorry to bump this but is there a discussion thread that corresponds to this proposal? I can't find it.