A bit off topic, yet still relevant given the ongoing attempts for D to be usable on the games industry.

At this year's GDC Unity had a few talks of the new subsystems being transitioning from internal engine code in C++ into upper layers written in C#.

For that purpose they are introducing a new compiler, based on LLVM and targeted to a subset of C# features, they are calling it High Performace C#.

Keypoints of the subset:

- Only structs are used, no classes;
- .NET collections are replaced by native collections that manage their own memory
- No code that would trigger GC is allowed
- Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations

They plan to take advantage of the new C# 7.x ref type features after integrating the new compiler infrastructure.

"Unity at GDC - C# Sharp to Machine Code"

https://www.youtube.com/watch?v=NF6kcNS6U80

Also relevant,

"Job System & Entity Component System"
https://www.youtube.com/watch?v=kwnb9Clh2Is

"A Data Oriented Approach to Using Component Systems"

https://www.youtube.com/watch?v=p65Yt20pw0g

Some might remember Mike Acton's talk at CppCon about data-oriented programming, he is one of the developers leading this effort.

https://www.mcvuk.com/development/exclusive-unity-takes-a-principled-step-into-triple-a-performance-at-gdc

On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
> A bit off topic, yet still relevant given the ongoing attempts for D to be usable on the games industry.
>
> At this year's GDC Unity had a few talks of the new subsystems being transitioning from internal engine code in C++ into upper layers written in C#.
>
> For that purpose they are introducing a new compiler, based on LLVM and targeted to a subset of C# features, they are calling it High Performace C#.
>
> Keypoints of the subset:
>
> - Only structs are used, no classes;
> - .NET collections are replaced by native collections that manage their own memory
> - No code that would trigger GC is allowed
> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>
> They plan to take advantage of the new C# 7.x ref type features after integrating the new compiler infrastructure.
>
> "Unity at GDC - C# Sharp to Machine Code"
>
> https://www.youtube.com/watch?v=NF6kcNS6U80
>
> Also relevant,
>
> "Job System & Entity Component System"
> https://www.youtube.com/watch?v=kwnb9Clh2Is
>
> "A Data Oriented Approach to Using Component Systems"
>
> https://www.youtube.com/watch?v=p65Yt20pw0g
>
> Some might remember Mike Acton's talk at CppCon about data-oriented programming, he is one of the developers leading this effort.
>
> https://www.mcvuk.com/development/exclusive-unity-takes-a-principled-step-into-triple-a-performance-at-gdc

Interesting that they are going the "No classes allowed" approach. It looks like the bullet points can be done in better c mode of D.

Regardless, I been pushing for a way to deallocated classes in the @nogc context, which apparently not very much people here seemed to care about.

On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>
>> - Only structs are used, no classes;
>> - .NET collections are replaced by native collections that manage their own memory
>> - No code that would trigger GC is allowed
>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations


The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.

So in C# you can write code like this:

interface IRange<T>
{
   void popFront();
   bool empty();
   T front();
}

struct MyRange<T>: IRange<T>
{
  //implementation
}

void foo<T>(IRange<T> someRange)
{
   //do something with someRange even it's a struct
   //this includes code completion and other IDE specific stuff.
}


In D, template constrains are not very clean and they not have IDE support:

void foo(T)(T someRange) if (isInputRange!T)
{

}

On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
> On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>>
>>> - Only structs are used, no classes;
>>> - .NET collections are replaced by native collections that manage their own memory
>>> - No code that would trigger GC is allowed
>>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>
>
> The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.
>
> So in C# you can write code like this:
>
> interface IRange<T>
> {
>    void popFront();
>    bool empty();
>    T front();
> }
>
> struct MyRange<T>: IRange<T>
> {
>   //implementation
> }
>
> void foo<T>(IRange<T> someRange)
> {
>    //do something with someRange even it's a struct
>    //this includes code completion and other IDE specific stuff.
> }
>
>
> In D, template constrains are not very clean and they not have IDE support:
>
> void foo(T)(T someRange) if (isInputRange!T)
> {
>
> }

Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.

On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
> On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
>> On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>>>
>>>> - Only structs are used, no classes;
>>>> - .NET collections are replaced by native collections that manage their own memory
>>>> - No code that would trigger GC is allowed
>>>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>>
>>
>> The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.
>>
>> So in C# you can write code like this:
>>
>> interface IRange<T>
>> {
>>    void popFront();
>>    bool empty();
>>    T front();
>> }
>>
>> struct MyRange<T>: IRange<T>
>> {
>>   //implementation
>> }
>>
>> void foo<T>(IRange<T> someRange)
>> {
>>    //do something with someRange even it's a struct
>>    //this includes code completion and other IDE specific stuff.
>> }
>>
>>
>> In D, template constrains are not very clean and they not have IDE support:
>>
>> void foo(T)(T someRange) if (isInputRange!T)
>> {
>>
>> }
>
> Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.

To clarify, the struct will be boxed when passing it to a function that accepts an IFoo, or if you do `IFoo foo = someStruct` or the like.

On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
> On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>>
>>> - Only structs are used, no classes;
>>> - .NET collections are replaced by native collections that manage their own memory
>>> - No code that would trigger GC is allowed
>>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>
>
> The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.
>
> So in C# you can write code like this:
>
> interface IRange<T>
> {
>    void popFront();
>    bool empty();
>    T front();
> }
>
> struct MyRange<T>: IRange<T>
> {
>   //implementation
> }
>
> void foo<T>(IRange<T> someRange)
> {
>    //do something with someRange even it's a struct
>    //this includes code completion and other IDE specific stuff.
> }
>
>
> In D, template constrains are not very clean and they not have IDE support:
>
> void foo(T)(T someRange) if (isInputRange!T)
> {
>
> }

You can do that in D too - see Atila's concepts library.

On Tuesday, 3 April 2018 at 01:31:12 UTC, Laeeth Isharc wrote:
> On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
>> On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>>>
>>>> - Only structs are used, no classes;
>>>> - .NET collections are replaced by native collections that manage their own memory
>>>> - No code that would trigger GC is allowed
>>>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>>
>>
>> The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.
>>
>> So in C# you can write code like this:
>>
>> interface IRange<T>
>> {
>>    void popFront();
>>    bool empty();
>>    T front();
>> }
>>
>> struct MyRange<T>: IRange<T>
>> {
>>   //implementation
>> }
>>
>> void foo<T>(IRange<T> someRange)
>> {
>>    //do something with someRange even it's a struct
>>    //this includes code completion and other IDE specific stuff.
>> }
>>
>>
>> In D, template constrains are not very clean and they not have IDE support:
>>
>> void foo(T)(T someRange) if (isInputRange!T)
>> {
>>
>> }
>
> You can do that in D too - see Atila's concepts library.

interface IFoo {
    int foo(int i, string s) @safe;
    double lefoo(string s) @safe;
}

@implements!(Foo, IFoo)
struct Foo {
    int foo(int i, string s) @safe { return 0; }
    double lefoo(string s) @safe { return 0; }
}

// doesn't compile
/*
@implements!(Oops, IFoo)
struct Oops {}
*/

On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
> On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:

>>
>> void foo<T>(IRange<T> someRange)
>> {
>>    //do something with someRange even it's a struct
>>    //this includes code completion and other IDE specific stuff.
>> }
>>
>>
>> In D, template constrains are not very clean and they not have IDE support:
>>
>> void foo(T)(T someRange) if (isInputRange!T)
>> {
>>
>> }
>
> Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.

HPC# allows interface inheritance, but does not box structs. It's clearly stated in the video (15:30). In fact, boxing would bring up the GC, and GC is not allowed in HPC#.

On 03/04/2018 11:01 AM, Meta wrote:
> On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
>> On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
>>> On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
>>>>>
>>>>> - Only structs are used, no classes;
>>>>> - .NET collections are replaced by native collections that manage their own memory
>>>>> - No code that would trigger GC is allowed
>>>>> - Compiler is aware of Unity features and is able to explore SIMD, by doing auto-vectorization, and transparently transform structs fields into optimal representations
>>>
>>>
>>> The struct type in C# is more versatile than the D's equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface.
>>>
>>> So in C# you can write code like this:
>>>
>>> interface IRange<T>
>>> {
>>>    void popFront();
>>>    bool empty();
>>>    T front();
>>> }
>>>
>>> struct MyRange<T>: IRange<T>
>>> {
>>>   //implementation
>>> }
>>>
>>> void foo<T>(IRange<T> someRange)
>>> {
>>>    //do something with someRange even it's a struct
>>>    //this includes code completion and other IDE specific stuff.
>>> }
>>>
>>>
>>> In D, template constrains are not very clean and they not have IDE support:
>>>
>>> void foo(T)(T someRange) if (isInputRange!T)
>>> {
>>>
>>> }
>>
>> Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
> 
> To clarify, the struct will be boxed when passing it to a function that accepts an IFoo, or if you do `IFoo foo = someStruct` or the like.

Shame we don't have signatures, then we'd have similar functionality only better!

https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md

On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
> - No code that would trigger GC is allowed

Impressive! It definitely won't be anyhing like D or Rust in systems field anyway, but C# usually feels to be so reliant in GC that this sounds wonderous nonetheless! Especially if, even without its core feature, classes, it's worthy as a c++ replacement where applicable.

I should really check this at some point.