On Friday, 24 July 2015 at 00:55:35 UTC, Tofu Ninja wrote:
On Thursday, 23 July 2015 at 20:09:34 UTC, Walter Bright wrote:
On 7/23/2015 7:49 AM, ixid wrote:
If we had a clean sheet wouldn't it be better to have if
return a value and
ditch ternary?
Then we'd start seeing code like:
x = 45 + if (y == 10) { while (i--) z += call(i); z; }
else { switch (x) { case 6: foo(); y; } + tan(z);
I.e. the embedding of arbitrary statements within expressions.
We already have some of this with embedded anonymous lambda
support, and I've discovered one needs to be very careful in
formatting it to not wind up with an awful unreadable mess.
So I'd be really reluctant to continue down that path.
Now, if you want to disallow { } within the embedded if
statement, then the proposal becomes nothing more than:
? => if
: => else
which is a potayto potahto thing.
I agree that trivial syntax issues actually do matter, but
having used ?: a lot, I have a hard time seeing embeddable
if-else as a real improvement, in fact I find it more than a
little jarring to see.
I think I agree on the if else issue, seems arbitrary as we
already have ?:. Other statements as expressions have less
obvious meanings. The only part is that I wish you could have
blocks as expressions. The thing is with ufcs, it really should
be possible.
For example the following does not compile:
int a = {return 4;};
but the following does:
int a = {return 4;}();
I know it's a really small difference, but with UFCS, I would
expect you the be able to omit the () and have the function
literal called automatically. Though I can see that this would
have problems with auto and knowing if it should be a function
pointer or to call the function.
I guess what I would expect is "auto a = {return 4;};" to type
a to a function pointer, but if you explicitly type a to int
then the literal should be called.
Does UFCS even apply to function pointers? I guess it is a
problem, it does not seem to be obvious when to call and when
to copy the pointer. I don't really know what should happen. I
think I read a dip a little while ago that might have addressed
this, but I don't really remember. I dont know, now that I have
written this, it seems to have more problems than I originally
thought.
Actually now that I think about it, I think I would expect auto a
= { return 4;}; to type a to an int and call the function
literal, and auto a = &{ return 4;}; to type a to a function
pointer. I think that makes sense. Then if a is a function
pointer auto b = a; would type b to a function pointer as well. I
suppose UFCS really does not make sense to function pointers, but
does make sense for function literals.
I expect {return 4;} to just be an anonymous function, not a
pointer to an anonymous function. That way you can write alias f
= {return 4;}; which would just be an alias to a function, which
makes sense. I haven't thought about how this would apply to
delegates.
