What, no design notes?

[DavidArno]

Hello @MadsTorgersen et al.

There have been no design notes from the dev team since May; over two months ago. Aside from Mads appearing on .NET Rocks and disingenuously claiming that in C# 7, pattern matching will be 80% done (the real figure will be nearer 8% than 80), there haven't been any announcements on progress and plans.

Any chance of an update soon?

Thanks.

[jmarolf]

It might be worth having a wiki page with links to all of them,

Good idea. Might improve discoverability. I think everyone has their own workflow for how they track progress on this repo, I don't think it would hurt to have another way.

I agree though that the tool writers and users of Roslyn have tough times finding documentation and samples. This kind of support was great at the beginning of the project but has now somewhat diminished.

I agree here. Unfortunately I don't know what sort of discussion we should have as a community. The way forward seems clear: we should publish more documentation and samples and ensure that those we publish are of high quality. I am to blame for some of that as I have not been giving samples the attention they deserve as of late. Again, not much I feel needs discussion, we should just do it.

I am glad there is a single place for Roslyn and I would be cautious about splitting. I need to follow like 6 repositories of ASP.NET to have at least some idea of what's going on there and that's not exactly great. People are filing issues at repositories they are not supposed to, many updates are just "react to changes in other repository" and it's just.. not fun.

I hear you loud and clear and I don't personally want separate repos for C#, VB, IDE, Debugger, etc. However, I think it would be great if all the language specs were in a separate repo as markdown files and as language discussion happened we would merge in changes to the specs. Does that also sound laborious?

[iam3yal]

@jmarolf

I hear you loud and clear and I don't personally want separate repos for C#, VB, IDE, Debugger, etc. However, I think it would be great if all the language specs were in a separate repo as markdown files and as language discussion happened we would merge in changes to the specs. Does that also sound laborious?

Sounds excellent to me, however, in my opinion it seems like there's a need for 4 repos.

1. This repo where implementation, discussions and stuff are taking place.
2. A repo for the language specs.
3. A repo for the Roslyn APIs.
4. A repo for the website.

I don't know but maybe 3 and 2 or 3 and 4 can share the same repo if it makes sense but Roslyn APIs aren't really documented, isn't? I know that there's this but it's not really up-to-date, right? so maybe it's time to do something about this too. :)

The ASP.NET team have a repo for their docs that the community can contribute to and help with it, can be a great idea to do the same here, I think, again, just my personal opinion. :)

What do you think?

[jmarolf]

@eyalsk I like this. It reads as 4 separate repos to me,

This repo where implementation, discussions and stuff are taking place.

I read that as read that as this repository dotnet\roslyn.

A repo for the language specs.

Something we need to create like dotnet\roslyn-language-specification

A repo for the Roslyn APIs.

Perhaps this a version of our current wiki that people can contribute to like typescript, with the idea that we would greatly expand it over time. Or like @eyalsk suggests, we could have a separate docs repo like asp.net that would be hosted on a separate website. If we do go with a separate website what do we want to do with our wiki? Should we still keep it but have different information there? What does everyone think?

A repo for the website.

Presumably we would redirect roslyn.io here as well as some C# and VB specific urls. The repo being something like roslyn-website

[AdamSpeight2008]

I like the idea of a separate website (or git repo) for document and specification, but only for versions released.It then can be used for asking usage questions, rather than them getting intermingle with roslyn design and build questions. The roslyn wiki should be for in flux features / api.

[ghord]

Separate repo for language design is excellent idea. Right now, newcomer has to dig through thousands(!) off issues, most of them unconnected to design process which I think is a major barrier.

It would also allow pulling all design markdown files from different branches in roslyn repo into one place.

[vbcodec]

@jmarolf Do Mads must write design notes ? Other members also may post these design notes.

We do not need transcript of every discussions, that guide sprints. We need to known important events. Important means:

• team decided to implement new / dropped (in previous version) feature. These notes are aimed mainly for discussions and feedback. Team should actively participate in these discussions, as this is core of 'developing with community'
• team decided to drop feature. There should be some explanations why it was dropped, if / when it may return etc
• team changed feature and that change have impact on experience while using this feature. This impact may be performance, syntax, semantic, limitations (or new possibiliteies) and anything other. For exapmle instead updating #12597, there should be posted new desing notes.

Design notes will form sort of chronicle, which will be useful, for someone who want to track development of the languages.

Team may also post implementation notes,, just to inform us that some feature was implemented fully / partially in prototype / final branch. Someone may be interested to try some features, despite it may be not complete.

New site should be great for C#/VB, but not something like http://www.typescriptlang.org, which is few static pages with links and few examples. We need site that is real HQ of languages, something like http://dlang.org. Such site should contain design notes, discussions, examples, links, articles blogs, sharing experiences by team while designing language and by users while using languages and anything other important to these languages. Github should be reduced to code repository, basic informations and posting bugs.

[jmarolf]

@AdamSpeight2008

separate website .. only for versions released. roslyn wiki should be for in flux features / api.

I don't get the distinction here. Couldn't we just have a separate branch of the documentation repo? Why do you feel documentation for in-development features is best served on the wiki? Are you thinking that this is more about implementation notes than documentation while features are in development?

@vbcodec

We do not need transcript of every discussions, that guide sprints. We need to known important events.

If I am interpreting you correctly, you want a summary of the decisions made after an LDM meeting posted shortly after the meeting concludes. Do you also want a detailed write-up of the thoughts that went into those decisions or do you just want the summary?

but not something like http://www.typescriptlang.org ... We need site that is real HQ of languages

I agree that we shouldn't just do exactly what the typescript homepage does. We should put all the things there that the community and new users cares about. You list some examples later, but what do you feel are the best parts about http://dlang.org? What information would you personally find valuable?

Github should be reduced to code repository, basic informations and posting bugs.

Could you elaborate on why this would be better? It seems you are suggesting that we have our own forums etc. that do not interact with the GitHub community at all. Is there something about GitHub that is lacking? How specifically does the D languages approach play out in practice for people that want to be a part of language discussions?

[AdamSpeight2008]

@jmarolf Lets say Pattern-Matching is released to public via an official release, eg VS15 but some parts of proposal didn't make it, say recursive patterns.

Doc Repo
   \ Pattern Matching

Roslyn Wiki
  \ Recursive Patterns

There is nothing stopping use put a link from documentation repo to the "Experimental" features of the Roslyn wiki. The distinction is that the wiki is subject to change, the doc repo is Tenant: Compat.

[jmarolf]

@AdamSpeight2008 But wouldn't we just want Recursive Patterns to be in a vnext branch on the documentation repo?

I think we may want to constrain the wiki to just be about the in-and-outs of contributing to dotnet/roslyn while the documentation repo is about documentation of all the public apis that tool makers would use.

[iam3yal]

@jmarolf

If I am interpreting you correctly, you want a summary of the decisions made after an LDM meeting posted shortly after the meeting concludes. Do you also want a detailed write-up of the thoughts that went into those decisions or do you just want the summary?

Personally. I want to have the thoughts that went into these decisions, people can wait 3 weeks or an iteration before a summary is posted by Mads.

I agree that we shouldn't just do exactly what the typescript homepage does. We should put all the things there that the community and new users cares about. You list some examples later, but what do you feel are the best parts about http://dlang.org? What information would you personally find valuable?

I don't think that the TypeScript website is bad, I mean it's quite clear where things are and navigation is pretty simple, it supposed to be an informative website and that's how it was designed.

I kinda like the D front page but then when I go there I see this statement about the language and I really wonder how it will work in this imaginary website of ours that need to speak to different audiences and generally when you make a statement that has multiple faces it's never clear.

I really love the part where they give a brief explanation about D in the "Why D?" section as well as the middle section where they give a summary of "News, Learn, Community, Documentation, Contribute and Packages", it seems useful but it needs to be updated regularly to be really useful.

Now, to answer your question directly, I don't really know what best or/and useful means, I mean when a person comes to a website he/she probably ask themselves "Where do I need to go to accomplish this thing or things?" as opposed to "Where do I want to be?"

So if I'm going to build this imaginary website and this website should be the central place for people to get information I'd probably focus on 4 main things and prioritize them as follow:

1. Layout and Navigation

   This is important for any website but even more so when the website needs to speak to different audiences.

2. Documentation

   The documentation needs to be clear and approachable to all people on all levels, e.g., language references, language specifications, Roslyn APIs all of these things need to have a central place in the website.

3. Community

   This page is going to answer questions like "Where do I ask questions about language X", "Where do I ask questions about Roslyn?", "Where do I post feedback?", "Where can I contact the community?", etc...

4. Tutorials

   Resources and learning materials that are posted both by the team or by the community, whether it's blogs, videos, etc...

Github should be reduced to code repository, basic informations and posting bugs.

Just to voice my opinion about it, I strongly, heavily, totally disagree with this! GitHub is a great place for discussions, it's easy to label things and track things, it makes it easy for the team to see on going discussions and for people to mention other people or reference discussions, really I don't think we need to externalize this because it works pretty good, yes it can be improved but that's up to GitHub.

The point is to make things more transparent not more complex and a forum definitely brings complexity.

Could you elaborate on why this would be better? It seems you are suggesting that we have our own forums etc. that do not interact with the GitHub community at all. Is there something about GitHub that is lacking? How specifically does the D languages approach play out in practice for people that want to be a part of language discussions?

As far as I know the design discussions of D are taking place in their forums.

[vbcodec]

@jmarolf

If I am interpreting you correctly ...

Design notes may be short summary or long detailed descriptions. It all depends how much quantity important (see my previous post) decisions was made, that affect developers. If team announce to add new feature, then we need detailed description of this feature. On the other hand, if feature was changed, in some important way (to us), then we need to know what was changed and why, and do not want to know all team's thought and discussions that was lead to this change.

..but what do you feel are the best parts about http://dlang.org?

IMO, there are no best part. This site provide full spectrum informations for anybody who want help or participate in development

How specifically does the D languages approach play out

Their approach is to use single site for any discussions, and that site is http://dlang.org, not github. Look at their github repos (https://github.com/dlang), there are no issues on most repos. They have on site forum, that is used to discussions, while github is only for code dump. This approach is good, because there is single site for any engagement, which is confortable.

[miloush]

@vbcodec GitHub is pretty much the 'single site for any engagement' with Roslyn, isn't it?

[vbcodec]

@miloush Not. Github is very focused on code repos, and all available features are to manage these repos. It was not designed to provide exhaustive support for project's sites in general way.

[iam3yal]

@vbcodec

GitHub is the site for any kind of engagement with Roslyn! currently we have no other alternatives unless you consider UserVoice that I really despise and dislike with all my heart.

I think that GitHub is a great place for discussions, whether you like it or not it's your choice! people can decide for themselves whether GitHub fits their need or not and it doesn't even matter what it was designed for as long as it fits your needs, it's simple.

Their approach is to use single site for any discussions, and that site is http://dlang.org, not github. Look at their github repos (https://github.com/dlang), there are no issues on most repos. They have on site forum, that is used to discussions, while github is only for code dump. This approach is good, because there is single site for any engagement, which is confortable.

So they have zero issues and they are going to a completely different site to post these issues where you cannot use mention and you cannot reference anything and you consider this a good approach... sorry but this doesn't make sense to me at all!

[vbcodec]

@eyalsk Now team must improve their engagement on github, by posting more design notes, clear some mess with issues and update obsolete non-code content. But github is not real HQ site, and labels are not real menus.

As for possible site, any forum's features may be added to provide great experience, the same or better than github,

[iam3yal]

@vbcodec What's good about menus? they are hierarchical, you can't filter them and nested menus aren't pleasant, labels are are used for navigation just like menus would, the only difference is menus are sorted (for you) and labels aren't, meaning, you have to use the search, personally I like the search.

Bottom line, I guess we will have to agree to disagree. :)

[ljw1004]

Swift does their language design over an email list. I read some interesting quotes...

That pipermail interface is barely an interface. I feel like the Swift guys are intentionally clinging to the mailing list as a method of weeding out contributors. If you want to participate, you have to put up with a pretty arcane communication system.

.

As a lurker curious about the language but not dedicated enough to read through a daily email log, I mostly get by with Erica Sadun's recaps.

.

I signed up for the mailing list and immediately regretted it. I am interested in helping, but this is miserable.

.

There's nothing arcane about using mailing lists for high volume discussion. They work extremely well for it and have for decades.

I personally manage a mailing list with ~20 posts per day. There's grumbling about email -- it's not archived, not easily searched, hard to keep track of the separate discussions. Some requested that we move over to github issues so it's easier to keep track of threads (with the idea that folks who prefer email can just rely on the github <-> email interface).

[AdamSpeight2008]

The design notes are important as some contributors may not have been part of the project since it inception, or have access to other microsoft resources.

[MgSam]

I've been taking a break from commenting after venting a little bit in that post in the top of the thread. Some thoughts on things people have suggested:

• More insight into what work is happening and why would definitely be appreciated. Also, involving the community in prioritization decisions would make more sense than what currently happens.
  • For instance, C# 7.0 is now confirmed to have dropped Source Generators. This makes the only "major" features, IMO, tuples and local functions. Both of these are pretty close to being syntax sugar and will not really enable new scenarios that weren't possible before. This means C# 6 and 7 will ultimately be syntax sugar releases. I would have gladly delayed every other C# 7 feature for Source Generators which many in the .NET ecosystem have been planning on in order to enable new functionality. Perhaps the larger community may have agreed or disagreed, but either way, they should have been given a vote.
• I don't think splitting into more repos makes anything easier. If tags are used effectively, it is quite easy to find the LDM notes. A link to a filtered view of the repo could also easily be put on the Github landing page.
• People got waaay too caught up in my comparison to TypeScript. TS is not the only language I compared to. For example, JavaScript and C++, 2 languages with code bases older and even larger than C#, are currently evolving much faster than C#. We have to stop sticking our heads in the sand here- C# is dropping in popularity, despite what Microsoft PR would have you believe. Every language popularity index has shown this.
  • I watched the video from Build this year where Mads proudly trumpeted C# being in the top 10 or something like that in popularity at Stack Overflow- a few years ago it was number one. The language needs to evolve or it will die- and the current (slow) pace of development just isn't cutting it. If this means the design team needs more team members or new leadership, then go out and hire them.

[vbcodec]

@MgSam Fresh or simple language may evolve faster than mature. While features increases linearly, complexity increases exponentially, so cadences must be longer.

[HaloFour]

@MgSam

I agree with everything you say.

This makes the only "major" features, IMO, tuples and local functions.

And type-switch. To be fair there is a lot of ground work being laid for pattern matching between type-switch, deconstruction and wildcards (7.1). I agree that source generators will be big and I think they will open a big sandbox in which potential new features can be explored without changing the language proper.

I don't think splitting into more repos makes anything easier.

I whole-heartedly agree. I think that good labels and a good/maintained wiki will solve nearly all of those problems. Plus a landing page for the language that can help users for different audiences explore the language and development process.

As for the popularity, I don't think that the language is the big problem there. It's the ecosystem. Until C# can run directly in the browser (or transpile to JavaScript), run natively on embedded devices with blazing-fast speed and run in Linux-based ecosystems I don't think C# can do a lot to compete with the top players. People aren't choosing to use Java, for example, because it has better language features.

That's not an excuse for the C# evolution to slow to a crawl. But it's important to solve the problems and not chase the fads.

[MgSam]

@vbcodec I doubt anyone would claim C++ is either "fresh" or "simple", yet that language is now evolving faster than C# as well.

@HaloFour I agree that platforms are part of the issue, but they're not the sole determinant. Xamarin is certainly a useful thing that people use, but when you're a team starting a new cross-platform project the case for using Xamarin gets harder and harder to make when C# is stagnating compared to the alternatives.

I think if no one higher-up at Microsoft admits there's a problem here it's not going to get fixed. The issues are a lot bigger than the frequency of Mads dropping off design notes. Anders doesn't lead C# development anymore. Who has taken his place? From my outsider perspective it appears to be no one. The language design process cannot succeed without effective leadership.

[AdamSpeight2008]

An example of why design notes are important, especially for offline discussions. Example

[CyrusNajmabadi]

Anders doesn't lead C# development anymore. Who has taken his place?

The design team leads together on this.

I think if no one higher-up at Microsoft admits there's a problem here it's not going to get fixed.

A lot more evidence needs to be presented to indicate there is actually a problem to the level that you are indicating :)

So far, i've heard a bunch of good feedback generally related to the difficulty it is to keep track of what's going on in a project as large as roslyn with github as the medium. There has also been requests for different types of organizational structures around how we do things. It's clear to me things could be tweaked slightly to make things far nicer for a certain segment of users we have. However, that's a far cry from the intimation that there's a very large problem going on.

[CyrusNajmabadi]

People got waaay too caught up in my comparison to TypeScript.

It's not that "people got waaay too caught up in the comparison". The point in the responses was to show why such comparisons are not suitable as different languages have different goals and issues they have to consider which can dramatically impact things like language velocity.

You cannot simply compare one language to another without considering deeply all the issues and concerns they have. There are pros and cons of the different sorts of approaches and release velocity is one factor among many.

[gafter]

I would have gladly delayed every other C# 7 feature for Source Generators

Dropping other features would not have helped. The difficulty with Source Generators is not the compiler - that part was fairly straightforward. The difficulty is getting all of the rest of the tooling working smoothly. There simply are not resources on the affected teams to get it all done in the C# 7 timeframe.

[jaredpar]

I would have gladly delayed every other C# 7 feature for Source Generators which many in the .NET ecosystem have been planning on in order to enable new functionality.

Expanding on what @gafter said here.

We actually invested considerable resources in source generators for this release. The compiler is the easy part and was done rather quickly. This is true even though the compiler work is actually two features: source generation and replace / overrides.

The challenge with source generators is not actually the language / compiler, it is instead the overall experience in the IDE. That includes semantic analysis, Intellisense, debugging, etc ...

From a compilation perspective source generators function a lot like analyzers. At a specific point in the compilation pipeline hand them a SyntaxTree, SyntaxNode, symbol, etc ... depending on how they registered. The output of the generator is a string which is immediately converted into a SyntaxTree and added to the pipeline. Some interesting items to consider with cycles + ordering but all very solvable.

From an IDE perspective though when to generate source is an enormous problem. This is essentially user code that can take an unbounded amount of time to complete. Yet the output of the generation is critical to the success of many IDE features.

Take Intellisense for example: Imagine if for example on generator is furiously spitting out extension members based on the code the user is currently typing. The only way Intellisense can be correct is if it considers the output of the generator based on the latest source code. That means functionally the generator must be run + completed on every key stroke before we display Intellisense.

That's a real problem. It essentially inserts 3rd party code directly into one of the most performance sensitive areas of the IDE. Doing so in this fashion is a recipe for bad performance and frustrated users.

An enormous amount of time in generators went to solving problems of this nature. A lot of progress was made here and we have worked out the basics of changes to the design that would make the feature significantly more palatable for a good development experience. But it does require a significant amount of work and it just doesn't fit into this release.

Perhaps the larger community may have agreed or disagreed, but either way, they should have been given a vote.

Voting wouldn't have helped here. The problem isn't that we didn't invest resources. Instead it's that the problem required more time than we had allotted for this release.

[vbcodec]

@MgSam C++ is not evolving faster. Their cadence is 3 years, while C# is average 2 years. C++ 11 was largest update with just new lamdas, type inference, and few minor tweaks. C++ 14 was minor tweaks, and C++ 17 is fail where all planned major features were rejected. They have serious issues with major features like concepts (over two decades of trials), GC, reflection, modules, async and others that are multi year dreams with many failed attempts. Java is not progressing at all, and other languages are irrelevant, C# delivers solid features with every release, and roslyn alone can be viewed as important feature especially for design team and other tools makers. Maybe tuples and type switch are just sugar syntax, but they are very useful, and this is most important for developers. C++ developers said for many years 'we have pointers to functions, so lamdas are not that necessary', but lambdas was added and now they say 'oh, it is so cool'.

[vbcodec]

@jaredpar While source generators may be problematic, but replace / original is free from such problems and code is delivered by developer, and this feature should stay in release. Replace / original is orthogonal to source generators, despite that they can be used together to provide highest potential.

[CyrusNajmabadi]

As a language designer, one of the things i steadfastly work to avoid is adding a feature too early. For example, say we added replace/original in this release. Then for the next release we really tackled SourceGenerators. Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

Now we're in a situation where we've got to maintain this feature from every moment forward. We also have to consider how this feature impacts everything else we do in every successive release. That's a burdensome tax that will hang around us forever and which will definitely slow down our release cycle.

I think it is very important that we put features in when we feel that they're not only great, but really make the most sense for the future of the language.

[miloush]

I always welcomed when the team decided not to push a feature into the release were they not 100% happy with it. Sometimes it prevented including things I personally found frightening, sometimes it prevented features I was looking forward to. Either way, it gives me a feeling of quality control in the process and I know that whatever makes it to the release is backed by sound design and firm belief of a team of experienced people that it is the right thing.

Unlike @MgSam, I think C# is evolving pretty fast, actually. You can't please everyone, but everyone can now try their own ideas and see how far they get. And if another language fits your task better, use that one instead. I agree that tooling is critical, if the IDE does not support it, the feature is practically dead from the beginning (XAML 2009, multi-module assemblies, ...)

I am also not concerned about the language "popularity". At the very least, I am not convinced that the fact that a language is so confusing that people have to ask questions about it is a good sign of anything.

[AnthonyDGreen]

Hey all,

@jmarolf suggested that one way we could give you more insight into what we've been working on is by posting a summary of our end-of-sprint review. So I posted the summary here. Check it out. There are some bits of work that aren't yet public but I figured it was better to let you know that there was activity on stuff that you just can't see yet that's taking up some of our time and attention. Let us know if you think this kind of summary is helpful to you. You can find the summary here: https://github.com/dotnet/roslyn/issues/12974

[iam3yal]

@CyrusNajmabadi

It's not that "people got waaay too caught up in the comparison". The point in the responses was to show why such comparisons are not suitable as different languages have different goals and issues they have to consider which can dramatically impact things like language velocity.

You cannot simply compare one language to another without considering deeply all the issues and concerns they have. There are pros and cons of the different sorts of approaches and release velocity is one factor among many.

Frankly, being more transparent and more engaged with the community has nothing to do with the product, it has nothing to do with complexity, it has a lot to do with the people working on the product and the process itself.

When we compared TypeScript and other teams at Microsoft to how things are done here we simply wanted to show that there are some teams that are doing it right and it's working for them, we didn't really compared products but we were speaking about the process of these teams working on different products, and when I speak about process in this discussion I really mean 1) How teams organize information? 2) How teams deliver this information to their communities? 3) How often this information gets to the community? these sorts of questions has nothing to do with how how mature the language is and how complex it is.

One of the things that I really think the team should do or at least start at is write a document that explains the current process and moving forward what it's going to be like.

Sorry if I've been blunt or harsh here, it isn't my intention to be disrespectful.

@AnthonyDGreen, @jmarolf and for the rest of the team thank you very much for posting the sprint summary, this is a great start!

[ljw1004]

@MgSam wrote: "This means C# 6 and 7 will ultimately be syntax sugar releases."

Also, async ValueTask which is a small feature, but not syntactic sugar, and it does open up a new way of coding -- libraries with async for their inner loops.

[vbcodec]

@CyrusNajmabadi

Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

Say 'hello' to my proposal #7300 where I've expressed scepticism for source generators and replace / original. Looks like team realized the same issues, mainly low performance and polluting language with unnecesary features. I've muted my scepticism when these features were promoted to 'high interest', but now I have new more complete proposal, that replaces rejected features, while preserving their goals and potential.

• Make methods / properties precedence for partial classes. Function / property in partial class will have higher precedence than function / property in non-partial class. The same function in two partial classes won't be allowed and raise error. This precedence will allow for 'code injection', which will be complementary to existing 'methods, properties and fields injection'. This will fix many issues while using partial classes.
• For AOP use IL code generation driven by metadata (similar to Postsharp). Alternaltivelly it may be implemented evem for JIT / Native code generation and will be available for any net language, but CLR team must be engaged This will save precious space in languages for better features
• Move source generators from Roslyn level to Visual Styudio level. There is need for some basic tooling that will raise events when files (any type, not only with code) are modified by VS. These events for files are: creating , save , change content (keystroke), delete , include and exclude. These events will be handled by library specified by project's settings. This library will be placed in project's folder which will ease move project between computers without losing ability to generate sources, if changes will be made to the files.

[AdamSpeight2008]

@ljw1004 Will there be an async valuetask analyser, that suggests a async value task could be a better approach.

[gafter]

@vbcodec

Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

... Looks like team realized the same issues, mainly low performance and polluting language with unnecesary features. I've muted my scepticism when these features were promoted to 'high interest', but now I have new more complete proposal, that replaces rejected features, while preserving their goals and potential.

Nothing has been rejected. @CyrusNajmabadi was just explaining that we have held back the replace/original feature until we have complete confidence that they fully solve the generator scenarios - which we will demonstrate by shipping them together when all the tooling is ready.

[CyrusNajmabadi]

:+1: on what Neal said. We still like this space, and i'm personally a fan of this source-based approach. But if we can't do it well, we should not rush something incomplete out the door. I'd much rather us spend the time necessary to make something amazing.

[vbcodec]

@CyrusNajmabadi , @gafter I am still sceptical especially for replace / original as tool for AOP (probably single important case for this feature). For simple AOP, replaced classes end up providing wiring (OnEnter/OnExit) to AOP system with linked subscribers. For more demanding AOP replaced classes will contain modified code copied from original methods, effectively doubling amount of code. This will decrease performance of editors to new level of sluggishness, as of today on newest CPU I can't avoid multi seconds pauses. This also will increase problems with source generators, where generators for C# can't be used with VB, and vice versa.

Better option is extensible system based on metadata and IL codegen, that will solve these problems created by replace / original.

[CyrusNajmabadi]

We should leave the discussion of SourceGenerators to appropriate threads on that topic. It would be inappropriate to get into a long discussion on that topic here. The core point i was making was that we believe it's better to spend the time to get features right, versus delivering potentially wrong features too early.

[iam3yal]

@jmarolf Is there anything going on with this website we proposed? or it's something that will come in the (shamelessly) far future?

I know you guys are probably very busy for RTM but can we expect to have one after it? I guess that's what I'm really asking. 😄

[jcouv]

The thread seems to have settled. I'll close the issue. Meeting notes are now getting posted at https://github.com/dotnet/csharplang/tree/master/meetings/2017