April 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

Is there an eta on this being submitted for consideration? Or has it already or?

Cheers
April 03, 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
April 03, 2018
On 03/04/2018 7:43 PM, aliak wrote:
> 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
> 
> Is there an eta on this being submitted for consideration? Or has it already or?
> 
> Cheers

No ETA, it is a major addition comparable to classes and I want to get it right.
April 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:
>> - 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.

The relevant point is that according to Miguel de Icaza interview at Unity's booth, the ongoing focus on performance was one of the contributors to the C# ref related improvements.

Then you have developers like Mike Acton which has a strong point of view on where C++ is going on game development, that has decided to join Unity and contribute to HPC# instead.
April 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.

April 03, 2018
On Tuesday, 3 April 2018 at 07:57:36 UTC, rikki cattermole wrote:
> On 03/04/2018 7:43 PM, aliak wrote:
>> 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
>> 
>> Is there an eta on this being submitted for consideration? Or has it already or?
>> 
>> Cheers
>
> No ETA, it is a major addition comparable to classes and I want to get it right.

Ok. Really looking forward to it! :)
April 03, 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:
>> 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#.

Oh, that's really neat (was on mobile and could not watch the video).
1 2
Next ›   Last »