Let me clarify the requirements and rephrase the question --
REQUIREMENTS
`assert`, `enforce` and the `unless` function I wrote (above) all
allow the condition to be expressed in an affirmative sense, and
they also achieve the goal of readability. These are the initial
requirements.
On Thursday, 18 June 2020 at 12:13:21 UTC, Denis wrote:
THE ESSENTIAL QUESTION
Is there a way to write an `unless` operator that would allow
the condition to be expressed in an affirmative sense? It would
be used like `if`, i.e. something like:
unless ( ) {
; // Or even:
I have an array of input data that I'm looping over, and, based on some
condition, generate new items that are appended onto a target array
(which may already contain data). Since the creation of new items is
quite expensive, I'm thinking to parallelize it with parallel foreach.
To avoid data
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:
if (not!(abra && cadabra)) ...
if (not(abra && cadabra)) ...
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:
No reason to use templates here
Pff. Me no think straight. -.-
On Tuesday, 12 December 2017 at 20:51:30 UTC, Steven
Schveighoffer wrote:
On 12/11/17 6:33 PM, Seb wrote:
[...]
Since iopipe was mentioned several times, I will say a couple
things:
[...]
I should really try iopipe this time round. I think I avoided
toying with it because the making
On Thursday, 18 June 2020 at 12:50:35 UTC, Stanislav Blinov wrote:
auto not(alias cond)() { return !cond(); }
if (not!(() => abra && cadabra)) ...
but that is indeed even less readable.
No reason to use templates here
```
pragma(inline, true) auto not(bool cond) { return !cond(); }
if
On Wednesday, 17 June 2020 at 14:32:09 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 June 2020 at 14:24:01 UTC, Stefan Koch wrote:
Parser in dmd does even inherit from Lexer.
why would a parser ever inherit from a lexer?
So you can write nextToken() instead of lexer.nextToken()
On 6/18/20 10:53 AM, aberba wrote:
On Tuesday, 12 December 2017 at 20:51:30 UTC, Steven Schveighoffer wrote:
On 12/11/17 6:33 PM, Seb wrote:
[...]
Since iopipe was mentioned several times, I will say a couple things:
[...]
I should really try iopipe this time round. I think I avoided
On Thursday, 18 June 2020 at 15:03:38 UTC, Steven Schveighoffer
wrote:
On 6/18/20 10:53 AM, aberba wrote:
On Tuesday, 12 December 2017 at 20:51:30 UTC, Steven
Schveighoffer wrote:
On 12/11/17 6:33 PM, Seb wrote:
[...]
Since iopipe was mentioned several times, I will say a couple
things:
On Thursday, 18 June 2020 at 13:58:33 UTC, Dukc wrote:
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:
if (not!(abra && cadabra)) ...
if (not(abra && cadabra)) ...
Which is a quite a complicated way to write
if (!(abra && cadabra)) ...
Oh an also https://github.com/dlang/dmd/pull/9899
On Thursday, 18 June 2020 at 12:50:35 UTC, Stanislav Blinov wrote:
No, there isn't a way to write an operator.
OK, first choice eliminated.
On Thursday, 18 June 2020 at 13:57:39 UTC, Dukc wrote:
No reason to use templates here
pragma(inline, true) auto not(bool cond) { return !cond(); }
I
On 6/18/20 5:13 AM, Denis wrote:
> Templates offer a clean syntax
Here is an earlier experiment of nested templates, which may be useful
in this case. This is unrelated to your problem but the syntax can be
pretty readable with templates:
// If there are template arguments, then the result
On Wednesday, 17 June 2020 at 11:50:27 UTC, Per Nordlöw wrote:
Should a range-compliant aggregate type realizing a parser be
encoded as a struct or class? In dmd `Lexer` and `Parser` are
both classes.
In general how should I reason about whether an aggregate type
should be encoded as a
On Thursday, 18 June 2020 at 17:57:49 UTC, Ali Çehreli wrote:
Here is an earlier experiment of nested templates, which may be
useful in this case.
:
I think you should be able to pass callables as 'alias'
template arguments
Sounds good. This gives me an opportunity to learn how nested
On Thursday, 18 June 2020 at 14:53:58 UTC, aberba wrote:
On Tuesday, 12 December 2017 at 20:51:30 UTC, Steven
Schveighoffer wrote:
On 12/11/17 6:33 PM, Seb wrote:
[...]
Since iopipe was mentioned several times, I will say a couple
things:
[...]
I should really try iopipe this time round.
17 matches
Mail list logo
