digitalmars.D - [OT] Unity migrating parts of their engine from C++ into High
- Paulo Pinto (29/29) Apr 02 2018 A bit off topic, yet still relevant given the ongoing attempts
- 12345swordy (7/36) Apr 02 2018 Interesting that they are going the "No classes allowed"
- rumbu (26/34) Apr 02 2018 The struct type in C# is more versatile than the D's equivalent,
- Meta (4/38) Apr 02 2018 Worth mentioning is that doing this necessarily causes the struct
- Meta (4/53) Apr 02 2018 To clarify, the struct will be boxed when passing it to a
- rikki cattermole (4/57) Apr 02 2018 Shame we don't have signatures, then we'd have similar functionality
- aliak (4/7) Apr 03 2018 Is there an eta on this being submitted for consideration? Or has
- rikki cattermole (3/13) Apr 03 2018 No ETA, it is a major addition comparable to classes and I want to get
- aliak (2/16) Apr 03 2018 Ok. Really looking forward to it! :)
- rumbu (3/6) Apr 03 2018 +1000
- rumbu (4/24) Apr 02 2018 HPC# allows interface inheritance, but does not box structs. It's
- Meta (3/28) Apr 03 2018 Oh, that's really neat (was on mobile and could not watch the
- Laeeth Isharc (2/36) Apr 02 2018 You can do that in D too - see Atila's concepts library.
- Laeeth Isharc (15/62) Apr 02 2018 interface IFoo {
- Mike Franklin (14/20) Apr 03 2018 I think you'll find Sarn's work on Xanthe quite interesting:
- Dukc (7/8) Apr 03 2018 Impressive! It definitely won't be anyhing like D or Rust in
- Paulo Pinto (7/15) Apr 03 2018 The relevant point is that according to Miguel de Icaza interview
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 For that purpose they are introducing a new compiler, based on 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 after integrating the new compiler infrastructure. 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
Apr 02 2018
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 For that purpose they are introducing a new compiler, based on 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 after integrating the new compiler infrastructure. 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-gdcInteresting 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.
Apr 02 2018
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote: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. 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) { }- 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
Apr 02 2018
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote: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.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. 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) { }- 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
Apr 02 2018
On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote: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 18:54:28 UTC, 12345swordy wrote: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.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. 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) { }- 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
Apr 02 2018
On 03/04/2018 11:01 AM, Meta wrote:On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:Shame we don't have signatures, then we'd have similar functionality only better! https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.mdOn Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote: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 18:54:28 UTC, 12345swordy wrote: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.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. 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) { }- 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
Apr 02 2018
On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:Shame we don't have signatures, then we'd have similar functionality only better! https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.mdIs there an eta on this being submitted for consideration? Or has it already or? Cheers
Apr 03 2018
On 03/04/2018 7:43 PM, aliak wrote:On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:No ETA, it is a major addition comparable to classes and I want to get it right.Shame we don't have signatures, then we'd have similar functionality only better! https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.mdIs there an eta on this being submitted for consideration? Or has it already or? Cheers
Apr 03 2018
On Tuesday, 3 April 2018 at 07:57:36 UTC, rikki cattermole wrote:On 03/04/2018 7:43 PM, aliak wrote:Ok. Really looking forward to it! :)On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:No ETA, it is a major addition comparable to classes and I want to get it right.Shame we don't have signatures, then we'd have similar functionality only better! https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.mdIs there an eta on this being submitted for consideration? Or has it already or? Cheers
Apr 03 2018
On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote: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+1000 This would be a very interesting development.
Apr 03 2018
On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:clearly stated in the video (15:30). In fact, boxing would bringvoid 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.
Apr 02 2018
On Tuesday, 3 April 2018 at 04:50:15 UTC, rumbu wrote:On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:Oh, that's really neat (was on mobile and could not watch the video).On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:It's clearly stated in the video (15:30). In fact, boxing wouldvoid 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.
Apr 03 2018
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:You can do that in D too - see Atila's concepts library.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. 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) { }- 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
Apr 02 2018
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: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 18:54:28 UTC, 12345swordy wrote:You can do that in D too - see Atila's concepts library.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. 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) { }- 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
Apr 02 2018
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote: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.I think you'll find Sarn's work on Xanthe quite interesting: https://forum.dlang.org/post/qjowkuwstewnmdunepiq forum.dlang.org https://forum.dlang.org/post/ntnvrdoqgjpuogoxexqn forum.dlang.org D provides some remarkable features (type introspection, mixins, templates, etc...) that could make something like this possible in 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.I think people care, but it's a difficult problem to solve due to the burden of some of D's technical debt. I know you are aware of the proposed ProtoObject which may provide an eventual solution. I, for one, am considering abandoning classes altogether and looking for ways to build on Sarn's aforementioned work to make object hierarchies in D using only structs. Mike
Apr 03 2018
On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:- No code that would trigger GC is allowedImpressive! It definitely won't be anyhing like D or Rust in 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.
Apr 03 2018
On Tuesday, 3 April 2018 at 07:29:11 UTC, Dukc wrote:On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:The relevant point is that according to Miguel de Icaza interview at Unity's booth, the ongoing focus on performance was one of the Then you have developers like Mike Acton which has a strong point of view on where C++ is going on game development, that has- No code that would trigger GC is allowedImpressive! It definitely won't be anyhing like D or Rust 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.
Apr 03 2018