Added: Meeting notes for July 13th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-07-13.md

Agenda:

• Triage open issues

[HaloFour]

@333fred I think you're doing a great job with the meeting notes! Keep up the good work! 🎉 🍻

[CyrusNajmabadi]

Agreed!

[333fred]

As long as we ignore the triaged issue I forgot to add to the list (now pushed and triaged correctly).

[liamlim]

I don't understand why trailing space in format specifier proposal was rejected.

Look at this code:

            var a = $"{ new DateTime():yyyy-mm-dd }"; // ERROR
            var b = $"{ new DateTime() }"; // OK
            var c = $"{ new DateTime():yyyy-mm-dd}"; // OK

Why is definition of b legal and definition of a is illegal? Definition of c just looks weird because there is space after { and no space before }. What exactly is the problem of allowing definition of a?

[HaloFour]

@liamlim

As mentioned in the notes the tricky thing is that while whitespace is trivial in the expression itself, it's not trivial as a part of the format specifier. The presence or absence of trailing whitespace almost certainly will cause the format specifier to be interpreted differently. It's not obvious that the compiler should trim that trailing whitespace.

[bbarry]

the format specifier in a (with trailing whitespace removed) gets executed roughly as if it was

var a = string.Format("{0}", default(DateTime).ToString("yyyy-mm-dd"));

The ambiguity is that with the whitespace it is unclear if it should execute as

var a = string.Format("{0}", default(DateTime).ToString("yyyy-mm-dd"));

or

var a = string.Format("{0}", default(DateTime).ToString("yyyy-mm-dd "));

[MillKaDe]

Blanks within and/or before are considered part of the format specifier ..

using System;
using static System.Console;
public class C {
  public static void Main() {
    var a = new DateTime();
    WriteLine ($"1: '{{ a:yyyy-MMM-dd}}' => '{ a:yyyy-MMM-dd}'");
    WriteLine ($"2: '{{ a:yyyy MMM dd}}' => '{ a:yyyy MMM dd}'"); // blanks between date parts
    WriteLine ($"3: '{{ a: yyyy MMM dd}}' => '{ a: yyyy MMM dd}'"); // + blank before date
  }
}

.. prints ..

1: '{ a:yyyy-MMM-dd}' => '0001-Jan-01'  
2: '{ a:yyyy MMM dd}' => '0001 Jan 01'  
3: '{ a: yyyy MMM dd}' => ' 0001 Jan 01'  

.. so it would be quite surprising, if a trailing blank would not be part of the format specifier.

That means, if trailing blanks would be allowed in a future C#, those blanks should be considered part of the format specifier, and not as white space between format specifier and the closing brace }.

Expressions in parenthesis ( .. ) allow white space before and after ..

bool b = true;  
WriteLine ($"4: '{{(b ? 'T' : 'F')}}' => '{(b ? 'T' : 'F')}'");
WriteLine ($"5: '{{ (b ? 'T' : 'F') }}' => '{ (b ? 'T' : 'F') }'");

.. which prints ..

4: '{(b ? 'T' : 'F')}' => 'T'  
5: '{ (b ? 'T' : 'F') }' => 'T'  

Unfortunately, that does not work for your original problem ..

WriteLine ($"6: '{{ (a:yyyy-MMM-dd) }}' ?=> '{ (a:yyyy-MMM-dd) }'");

.. does not compile ..

error CS8124: Tuple must contain at least two elements  
error CS0103: The name 'yyyy' does not exist in the current context  
error CS0103: The name 'MMM' does not exist in the current context  
error CS0103: The name 'dd' does not exist in the current context  

SharpLab: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEUCuA7AHwAEAmARgFgAoIgBgAIiylGyA6AYQjwGcIAbGAG5qRAMyMS9DvQDe1epKnyqixQDcAhlHqb6AXnp4YAd3oARTRhgAVAJYBbGAAoAlCNVqA6lDvWAMnbG9M4AJABEZCD0AOSysrogAJ4pSXAAsplwACbZAL55MQYAfLEJmsmpGVm5heHuCt6+AUEwIREk0XHllSn0men0tYUlZYmpSf2ZQ/kx9UL0APSL9MD8mngA1jyrMBgmMDB4Q1ZtAA7aGDyNij5+MIHBYeFiXfGJ9BNTg8NF+qVxD5fAYzOruJYrADUq3WW12ADNoG1sqcbqsIAJVgZ6BhcMJFGi7i0nhEUG9ZM5gPQAPyxGxFLoAMRirgKfwBFKptJi9PoTJZYI8anoRIerXa4QArOSQly6QzYszXPQ2aNAZSafK+YqWSq5g1PLdmmKSeEkDLnBUJtV0jlssrVdT/mNLb00gM7Q79UKVdQ8kA===

[CyrusNajmabadi]

.. so it would be quite surprising, if a trailing blank would not be part of the format specifier.

@liamlim

Yup. this was the exact issue. Indeed, when this came to the LDM the person presenting it said that if the user wrote $"{ new DateTime():yyyy-mm-dd }" that that should be a call to format the date, using the format string "yyyy-mm-dd ". In the meeting though, several people pointed out that their read of the original issue meant we would absolutely not be providing you with the feature you wanted.

i.e. you had $"Value: '{ a:yyyy-MM-dd }' and wanted that to mean the format string was "yyyy-mm-dd" not "yyyy-mm-dd ". We discussed if we should trim the end of the format string, and we couldn't come up with any rational for that esp as format-strings are whitespace sensitive in many cases (including the very datetime case you were asking about).

So we had no design that we felt made sense, so we outright rejected this.

[CyrusNajmabadi]

Definition of c just looks weird because there is space after

Note: this is because of a stylistic choice on your part, combined with usign a part of the language that is not whitespace sensitive and a part of it that is whitespace sensitive. C'est la vie.

[MgSam]

I see records is listed as merged. Did you guys finish the design work on it? It seemed like the last time it was discussed there were quite a few open issues remaining (including what the keyword would be called!) I'm also particularly interested in what you're going to do with ==.

[333fred]

We've been keeping the speclet up to date: https://github.com/dotnet/csharplang/blob/master/proposals/records.md

[MgSam]

Hmm, disappointed to see the record with no class attached hasn't been revisited being it was universally rejected by the community here.

Will there be another preview before shipping?

[CyrusNajmabadi]

Hmm, disappointed to see the record with no class attached hasn't been revisited

I don't see any feedback that changes our evaluation of the scenario. in other words, the concerns people raised were all things that were raised while we were discussing the options. We considered the pros/cons here, and ended up feeling that hte cons were minor and that we preferred the design that we ended up with.

[liamlim]

I understand design decisions about format specifier and the reasons why it's not possible to preserve trailing spaces. Thank you for letting me know. Just FYI this is not annoying just me but a whole company I am working in because trailing spaces in string interpolations are in our code style best practices. It makes sense to create error for ALL trailing spaces in string interpolation or for NONE of them. The current situation when it's disabled only in very specific case when we use format specifier is weird. The fact that var a = $"{ new DateTime() }"; is legal and var b = $"{ new DateTime():yyyy-mm-dd };" is illegal is in my opinion poor language design.

Please consider at least not offering IDE_0071 if applying this fix would result in removing trailing space from string interpolation. I currently don't have option to have var a = $"{ new DateTime().ToString("yyyy-mm-dd") }"; without annoying suggestion to simplify string interpolation which results in code against style policy of my company. I couldn't even find an option of disabling IDE_0071 in editorconfig and I can't disable IDE_0071 for every csproj project in a solution because it's just not a good design. If someone wants to add new csproj in future then they need to keep in mind to disable IDE_0071 which I don't like

[canton7]

@liamlim

I couldn't even find an option of disabling IDE_0071 in editorconfig

Or set it to:

dotnet_style_prefer_simplified_interpolation = false

(It doesn't appear in the docs it seems, see dotnet/roslyn#42695)

[liamlim]

This is exactly what I don't like about current .editorconfig situation. It's undocumented and it's pain to actually set what is needed (Suppress and Configure issues doesn't work for me quite often and doesn't modify .editorconfig at all). Wouldn't it be better to just be able to type "IDE_0071 = true:none" to .editorconfig instead of some fancy name which no one remembers. When I know exact code of issue I need to suppress I need to look for this fancy modifier just to be able to suppress it which is a pain. Those codes are well documented and I don't see why .editorconfig team felt need to create another identifiers which aren't documented anywhere and also are too long to remember.

Anyway thankts a lot for letting me know about this although it's not in docs or at least I wasn't able to find it.

[canton7]

@liamlim

(Suppress and Configure issues doesn't work for me quite often and doesn't modify .editorconfig at all)

Sounds like there's work to do there, then.

When I know exact code of issue I need to suppress I need to look for this fancy modifier just to be able to suppress it which is a pain.

I didn't know until about 40 minutes ago, when I asked VS and it told me what to use, see my screenshot above.

Wouldn't it be better to just be able to type "IDE_0071 = true:none" to .editorconfig instead of some fancy name which no one remembers.

You can write this:

dotnet_diagnostic.IDE0071.severity = none

See this prominent note here, which links here (and dotnet/roslyn#35690).