Is there a nice syntax to achieve optional named parameters?

[evilrat]

On Friday, 18 January 2019 at 09:39:31 UTC, John Burton wrote:
> On Thursday, 17 January 2019 at 01:43:42 UTC, SrMordred wrote:
>
>> struct Config
>> {
>> 	string title;
>> 	int width;
>> }
>>
>> struct Window
>> {
>> 	this(Config config)
>
> It likely is a bad idea for a small struct like this but if it 
> was much bigger would it makes sense to write this as :-
>
> 	this(const ref Config config)
>
> Which is what you might do in C++ or does D handle this 
> differently?

You'd better profile and only then act.
Seriously, whatever you know and familiar with in C++ might not 
work with D, you'll just end up with C++'ish code that just 
happens to be written in D.

D is not C++, and such premature optimizations might cause more 
harm if applied on occassion or out of habit.

IIRC D structs are all movable, so doing const refs here and 
there or using writing to ref parameter instead normal 
return(RVO) is likely bad for your code.

D has its own ABI, it's not even compatible with C++, so when you 
pass structs by value it may or may not produce similar asm as 
C++ compilers does.

When struct contains strings/arrays they are anyway managed by 
GC(unless you allocated it on your own), but this is something 
that more seasoned D users can explain in better details and 
cleaner explanation than me, if it means anything at all.

Even without all this, do you really want to mess up your 
codebase with implementation details about how it should do it, 
or write clean (self)documented code? Is it really going to be a 
bottleneck in your program? Passing one big struct at widget's 
creation on program startup and some rare events really going to 
kill performance?
Why not just write working code first and then identify 
bottlenecks and optimize when it absolutely ultimately necessary?
Btw I don't remember much ref parameters in phobos, just look at 
it... I found only 4 ref consts it in std.file, 3 in std.array, 
other modules more likely to have them in comparison operators(I 
have no idea why, to not introduce potential RVO case?) and in 
unit tests for testing correct behavior.

Again, D is not C++, what might work or even considered "good 
practice" there may or may not work here. So just profile it!