4 ms·

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't thin

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't think this is too valid of a concern.

gizmo 3y ago
Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.
- jbluepolarbear 3y ago
  So how would you solve the AOT (ahead of time compiling) problem without code generation? An entire ecosystem (Unity) that uses C# requires that code must be AOT for supporting IL2CPP (a low level translation of IL to c++). Dynamics and Reflection of non-AOT types are unavailable at runtime. IL2CPP came from Apples requirement that no JIT be run in apps and to get more performance; especially, for features like burst that allows writing C# that directly translates to high performance multithreaded c++.
  - pjc50 3y ago
    Different usage, I think: if people are talking about "language not expressive enough", they're referring to mechanisms for generating C#, or IL, not things further down the toolchain for AOT. System.Xml.Serialization, for example, relies on generating assemblies at runtime to work. That's "code generation", but of a kind that directly conflicts with the AOT meaning of "code generation".
- pjc50 3y ago
  You can't make a language fully general without it turning into a mess; things like the protobuf compiler are reasonable use cases for source generation.
  - deleted 3y ago
    [deleted]
- jddj 3y ago
  That's not really true. Source generation is used at some level to implement expressivity at minimal runtime cost. It's just operating at a different level of abstraction to make different tradeoffs. Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness. If you design around a Foo<bar> does it matter if behind the scenes it generates a FooOfBar? Should a language inherently care specifically about protobufs, flatbuffers, capnproto, etc because expressiveness or should it just have capable source generators for building strongly typed interfaces without the legwork? Are you sure an alternative implementation which is more expressive would be better or would it just be different?
  - gizmo 3y ago
    > Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness. Thinking those are the only options is exactly why the issue is expressiveness.
    - pjc50 3y ago
      Is this a reference to some specific, better, technique or an optimistic belief that such a thing could be built if only ..?
      - gizmo 3y ago
        Code generators are used because run-time introspection tends to be slow(er) and because debugging code generated at runtime is harder and because IDEs don't know how to deal with code generated at runtime. But there no reason why this should be so. No good reason to have a hard boundary between compiletime and runtime either. These are just historical artifacts.
  - pjmlp 3y ago
    That is really true, it is a workaround to avoid designing a proper macro system instead. Likewise the new interceptors infrastructure is a workaround to avoid implementing proper AOP support, like Microsoft Fakes.
- lozenge 3y ago
  One example would be a tool that you compile in and records some state after every LOC in a method which you are interested in. If you wanted to use a normal debugger at the same time you would usually be shown your code with the tool's generated code mixed in. With this you could step through just your code.
Mountain_Skies 3y ago
That's good to know. I wonder if VS and VS Code are set to at least produce warnings when the feature is used in human generated code. Any feature can be abused, will be abused. At least with warnings by default the programmer can know this isn't a desired use case and then decide if their particular need is a worthwhile exception.
- Rapzid 3y ago
  On the other hand if this oopsies its way into a codebase it could highlight a serious problem with the code review process..

Well, this features is designed to be used by source generators and not humans. So as it's intended for being used inside the compilation process, i don't think this is too valid of a concern.

gizmo 3y ago

Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.

jbluepolarbear 3y ago
So how would you solve the AOT (ahead of time compiling) problem without code generation? An entire ecosystem (Unity) that uses C# requires that code must be AOT for supporting IL2CPP (a low level translation of IL to c++). Dynamics and Reflection of non-AOT types are unavailable at runtime. IL2CPP came from Apples requirement that no JIT be run in apps and to get more performance; especially, for features like burst that allows writing C# that directly translates to high performance multithreaded c++.
- pjc50 3y ago
  Different usage, I think: if people are talking about "language not expressive enough", they're referring to mechanisms for generating C#, or IL, not things further down the toolchain for AOT. System.Xml.Serialization, for example, relies on generating assemblies at runtime to work. That's "code generation", but of a kind that directly conflicts with the AOT meaning of "code generation".
pjc50 3y ago
You can't make a language fully general without it turning into a mess; things like the protobuf compiler are reasonable use cases for source generation.
- deleted 3y ago
  [deleted]
jddj 3y ago
That's not really true. Source generation is used at some level to implement expressivity at minimal runtime cost. It's just operating at a different level of abstraction to make different tradeoffs. Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness. If you design around a Foo<bar> does it matter if behind the scenes it generates a FooOfBar? Should a language inherently care specifically about protobufs, flatbuffers, capnproto, etc because expressiveness or should it just have capable source generators for building strongly typed interfaces without the legwork? Are you sure an alternative implementation which is more expressive would be better or would it just be different?
- gizmo 3y ago
  > Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness. Thinking those are the only options is exactly why the issue is expressiveness.
  - pjc50 3y ago
    Is this a reference to some specific, better, technique or an optimistic belief that such a thing could be built if only ..?
    - gizmo 3y ago
      Code generators are used because run-time introspection tends to be slow(er) and because debugging code generated at runtime is harder and because IDEs don't know how to deal with code generated at runtime. But there no reason why this should be so. No good reason to have a hard boundary between compiletime and runtime either. These are just historical artifacts.
- pjmlp 3y ago
  That is really true, it is a workaround to avoid designing a proper macro system instead. Likewise the new interceptors infrastructure is a workaround to avoid implementing proper AOP support, like Microsoft Fakes.
lozenge 3y ago
One example would be a tool that you compile in and records some state after every LOC in a method which you are interested in. If you wanted to use a normal debugger at the same time you would usually be shown your code with the tool's generated code mixed in. With this you could step through just your code.

Mountain_Skies 3y ago

That's good to know. I wonder if VS and VS Code are set to at least produce warnings when the feature is used in human generated code. Any feature can be abused, will be abused. At least with warnings by default the programmer can know this isn't a desired use case and then decide if their particular need is a worthwhile exception.

Rapzid 3y ago
On the other hand if this oopsies its way into a codebase it could highlight a serious problem with the code review process..