On Sunday, 25 June 2017 at 16:50:38 UTC, Moritz Maxeiner wrote:
[...]
Just to be clear, I think that at least for now
out(result; result > 0, "worse enough")
is the best solution, and I support it.
Everything else are just some random ideas that I'm not pushing
strongly.
As expected, my proposal's grammar wasn't to well thought through
and
Guillaume Boucher provided a good example for that.
I have no stance with having to specify a result identifier, or
using __result, making `result` special, *but*: Not requiring
parentheses here introduces an unacceptable language
inconsistency:
auto x(T)(T t)
if (...)
in (...)
out ...
{
...
}
If you also propose to drop the parentheses for `in`, that
still leaves the inconsistency with `if`, i.e. now `if` must be
changed to also drop the parentheses in template constraints.
That, however, leads then to an inconsistency between different
uses of `if` and thus all other occurrences of `if` in the
grammar must now be made to work without parenthesis. This then
leads to even more inconsistencies with `for`, `while`, etc.
that now also will have to be changed.
No, I'm not proposing removing parenthesis in just one case -
I agree that it would be stupidly inconsistent and there's no
point in that. I proposed this:
T sqrt(T)(T n)
if Unqual!T U: isNumeric!U || is(U == BigInt)
in n >= 0
out (result) result * result == n
{
//Implementation
}
But as mentioned already, that has grammar ambiguities.
So what about something like this:
T sqrt(T)(T n)
where U is Unqual!T: isNumeric!U || is(U == BigInt)
require: n >= 0
ensure result: result * result == n
{
//Implementation
}
Assuming that in this particular case there's no need for custom
error
messages, which are still unsupported for template constraints
presently.
(I'm aware that this has low chances in getting into the language,
I'm just interested in hearing your unbiased opinion as if it was
targeted at a hypothetical D3.)
