Back in D after some absence, some perspective

Max Haughton maxhaton at gmail.com
Mon Mar 8 18:02:35 UTC 2021


On Monday, 8 March 2021 at 17:10:38 UTC, Timon Gehr wrote:
> On 08.03.21 16:39, deadalnix wrote:
>> On Monday, 8 March 2021 at 11:01:17 UTC, Timon Gehr wrote:
>>> On 02.03.21 22:05, deadalnix wrote:
>>>> I think it is hard too argue that D doesn't have enough 
>>>> feature at this time.
>>>
>>> OTOH, there is no pattern matching, in particular you can't 
>>> pattern match tuples. Therefore, it is also very hard to 
>>> argue that D is feature-complete. (Has it skipped leg day?)
>> 
>> While pattern matching would be nice, I place soundness above 
>> it.
>
> For me it's not even a close contender. There's no soundness 
> now and soundness is much harder to achieve than (or even 
> without) obvious fundamental features. In comparison, soundness 
> almost seems like a lost battle at this point.
>
>> Plus, if you look at the SDC codebase for instance, you'll see 
>> that you can go pretty far as a library.
>
>
> auto firstThingSecondThing=query!((ref foo)=>tuple(foo.a, 
> foo.b))(data);
> auto firstThing=firstThingSecondThing[0], 
> secondThing=firstThingSecondThing[1];
>
> Huge pain.
>
>
> auto (firstThing,secondThing)=query!((ref foo)=>(foo.a, 
> foo.b))(data);
>
> Much better.
>
> Whatever string mixin hack you can come up with is not good 
> enough.

I agree. I also think the weird tuple situation we have now has 
to look bad from afar, e.g. we have Phobos tuples which aren't 
great, dmd tuples which are weird, AliasSeq, T... etc. 
Furthermore, I read your proto-DIP about Tuples, and I think it's 
a good step forward, but it strikes me that maybe we should just 
go the whole way and have first-class tuples (Even just as a 
direct rewrite to a struct would be a step forward in terms of 
allowing the kind of unpacking syntax that I would hope almost 
everyone wants).






More information about the Digitalmars-d mailing list