Comes out cleaner because overriding a default argument doesn’t force you to also do all the positional arguments in front of it.
Designated initializers make it look really nice imo. I feel like the brackets are no big deal.
Python has sort of the opposite when you need to use *kwargs.
This is essentially what Vulkan does; there's a CreateInfo struct for every object creation or command function. And even then they managed to sort of mess it up, because they also have functions and objects suffixed with a '2', and the pNext extension mechanism.
…but I think the author meant “named arguments”, like we have in C#, Swift, and Objective-C.
They can be:
>>> def foo(bar=None):
... print(bar)
...
>>> foo()
None
>>> foo(bar="baz")
baz
>>> foo(bar="baz", baz="azp")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: foo() got an unexpected keyword argument 'baz'
But you can also use them generically: >>> def bar(**kwargs):
... print(kwargs)
...
>>> bar()
{}
>>> bar(site="HN", user="tonyarkles")
{'site': 'HN', 'user': 'tonyarkles'}https://docs.python.org/3/glossary.html?hl=en-GB#term-keywor...
int x = 5 <xor> 3; // x = 6
The basic trick was to notice that this is really parsed as: int x = ((5 < xor) > 3);
which you could implement with (roughly): struct XorType1 { ... } xor;
struct XorType2 {
int left;
XorType2(int left) : left(left) {}
int operator>(int right) const {
return left ^ right;
}
};
XorType2 operator<(int left, XorType1 const& ignored) {
return XorType2(left);
}
But I sat on this for a while and later discovered someone else had already come up with it :-/EDIT: Thanks commenter hawkice for fixing my XOR arithmetic!
See https://en.cppreference.com/cpp/language/operator_alternativ...