The main check is in place, but I still need to fiddle about the way the modreq stuff works, I initially believed it was an attribute.

Main blocker: in the current added test, the csharp compiler doesn't seem to be the right version for handling 'init' keyword:

// TestFramework.fs line 288
let CSC = requirePackage ("Microsoft.Net.Compilers" ++ "2.7.0" ++ "tools" ++ "csc.exe")

@KevinRansom / @brettfo is it something you would update for me in main branch or any other preferred route?

Other questions to nail the code the best for later review:

• is there any precedent of modreq metadata in our IL reading and TcGlobals infrastructure?
• AFAIU, unlike how we do with attributes in TcGlobals, kept as BuiltinAttribInfo, are we fine with just string matching (it seems good enough per the way C# compiler does) if there is no infrastructure around modreq
• since the feature is just a type checking, and there is no runtime implication (setter can still be called by reflection or if the compiler let it go in type checking), do we keep the set_PropertyName escape hatch (it just works since Fixed extra emitted pop when consuming IL types with init properties #11552 is merged) to still be able to call the setter this way?

pieces of information for my own reference:

• https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/proposals/csharp-9.0/init.md
• https://github.com/dotnet/csharplang/blob/3c8559f186d4c5df5d1299b0eaa4e139ae130ab6/meetings/2020/LDM-2020-04-06.md
• New API: InitOnlyAttribute runtime#34978

@smoothdeveloper That's certainly an old C# compiler. I have no issue with updating to the latest stable of 3.9.0, but I'd like to give @KevinRansom and @TIHan a chance to say if they want to stick with 2.7.0.

If we do update that version, it'll have to be changed both here and here (and possibly here).

I found one more location where the path to csc.exe needs to be updated:

Thanks @brettfo / @KevinRansom, I've updated the pointers to csc.exe and it works as I expect.

I'll need to update FCS surface area (will do it on top of #11574 once merged).

Remaining decision is whether we still support set_PropertyName or not.

Any updates regarding this? It's still experimental, but what would we need to do to make it past that?

Might be a bit of an ask, but if the breaking-ness of this change is what's holding it up, it would be nice to have it produce a warning in the meantime. Then I can be sure I'm not shooting myself in the foot.

@TIHan, if anyone can give it a rebase, I can't work on it right now.

The changes to compiler were functionally OK AFAIR.

@reinux in current implementation, you can still call set_ member instead:

This is open for discussion if we should remove it.

@TIHan, if anyone can give it a rebase, I can't work on it right now.

The changes to compiler were functionally OK AFAIR.

@reinux in current implementation, you can still call set_ member instead:

fsharp/tests/fsharp/typecheck/init-property/niceinit.fsx

Line 7 in 5bcccd0

niceinit2.set_Val 5;;

This is open for discussion if we should remove it.

By current implementation, I'm assuming you mean the PR, right? Anything that'll help move this PR along 😁

Just a fairly unsophisticated, average user's opinion to add to the discussion:

I do worry a little these days that F# is straying from C# a bit, especially with nullability and such. With C#'s feature set catching up, F#'s biggest pitch is its cleanliness, so although I can see some situations where set_ could be useful, it might make the most sense to try to adhere to C#'s rules a bit.

Fixed in #13490