> On Friday, 21 January 2022 at 17:25:20 UTC, Ali Çehreli wrote:
[...]
> > Additionally, just because we *provide* a step, now we *require*
> > division from all types (making it very cumbersome for user-defined
> > types).
[...]
It doesn't have to be this way. We could just use DbI to inspect whe
On Friday, 21 January 2022 at 17:25:20 UTC, Ali Çehreli wrote:
Ouch! I tried the following code, my laptop got very hot, it's
been centuries, and it's still running! :p
:)
```d
size_t length() inout {
auto len = 1 + (last - first) / step;
return cast(size_t)len;
}
```
Does t
On 1/21/22 08:58, Salih Dincer wrote:
> ```d
> auto inclusiveRange(T)(T f, T l, T s = cast(T)0)
> in(!isBoolean!T) {
'in' contracts are checked at runtime. The one above does not make sense
because you already disallow compilation for 'bool' below.
You could add a template constraint there:
On Thursday, 20 January 2022 at 16:33:20 UTC, Ali Çehreli wrote:
So if we add the 1.0 value after 0.900357627869 to be
*inclusive*, then that last step would not be 0.3 anymore.
(Thinking about it, step would mess up things for integral
types as well; so, it must be checked during constru
On 1/19/22 21:24, Salih Dincer wrote:
> ```d
>size_t length() inout {
> //return last_ - first_ + 1 - empty_;/*
> auto len = 1 + last_ - first_;
> return cast(size_t)len;//*/
>}
> ```
Good catch but we can't ignore '- empty_'. Otherwise an empty range will
return 1.
> B
Hi,
It looks so delicious. 😀 Thank you.
On Wednesday, 19 January 2022 at 18:59:10 UTC, Ali Çehreli wrote:
And adding length() was easy as well.
Finally, I have provided property functions instead of allowing
direct access to members.
It doesn't matter as we can't use a 3rd parameter. But
On 1/19/22 04:51, Salih Dincer wrote:
> Is it okay to swap places instead of throwing an error?
I would be happier if my potential mistake is caught instead of the
library doing something on its own.
> Let's also
> implement BidirectionalRange, if okay.
I had started experimenting with that
On Tuesday, 18 January 2022 at 23:13:14 UTC, Ali Çehreli wrote:
But I like the following one better because
it is fast and I think it works correctly.
Is it okay to swap places instead of throwing an error? Let's
also implement BidirectionalRange, if okay. This great struct
will now run 4x4
void using number ranges 'directly', and
instead use a wrapper function...
auto range(T:T)(T a, T b)
{
import std.range : iota;
return iota(a, (b+1));
}
Aww, come on; it ain't that bad...
Well that depends on entirely on what the code is doing ;-)
The key is to *always*
On Tuesday, 18 January 2022 at 20:43:08 UTC, forkit wrote:
On Tuesday, 18 January 2022 at 16:02:42 UTC, Tejas wrote:
Newer languages nowadays use `start..intent, think it's something we should follow?
I've decided to avoid using number ranges 'directly', and
instead us
On Tuesday, 18 January 2022 at 17:58:54 UTC, H. S. Teoh wrote:
On Tue, Jan 18, 2022 at 04:02:42PM +, Tejas via
Digitalmars-d-learn wrote: [...]
Newer languages nowadays use `start..intent, think it's something we should follow?
I've never seen that before. Which languages use that?
T
I
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
This will immediately make whoever reads the code (i.e., myself
after 2 months :D) wonder, "why +1?" And the answer will become
clear and enlightenment ensues. ;-)
In those cases i find myself rewriting said code. Generally to
say
On 1/18/22 14:08, forkit wrote:
> never use number ranges.. not ever! ;-)
>
> (except in combination with iota)
Indeed, the following is an elegant but slow (tested with dmd)
implementation with Phobos:
auto range(T)(T a, T b)
in (a <= b) {
import std.range : chain, iota, on
7;int', the range
will produce ints.
Ali
a change of mind...
never use number ranges.. not ever! ;-)
(except in combination with iota)
On 1/18/22 12:43, forkit wrote:
> wrapper function...
>
>
> auto range(T:T)(T a, T b)
> {
> import std.range : iota;
> return iota(a, (b+1));
> }
Needs a little more work to be correct. The following produces and empty
range. ;)
range(uint.min, uint.max)
Also, is it important for
On Tuesday, 18 January 2022 at 16:02:42 UTC, Tejas wrote:
Newer languages nowadays use `start..intent, think it's something we should follow?
I've decided to avoid using number ranges 'directly', and instead
use a wrapper function...
auto range(T:T)(T a, T b)
{
imp
On Tue, Jan 18, 2022 at 04:02:42PM +, Tejas via Digitalmars-d-learn wrote:
[...]
> Newer languages nowadays use `start.. it's something we should follow?
I've never seen that before. Which languages use that?
T
--
"If you're arguing, you're losing." -- Mike Thomas
On Monday, 17 January 2022 at 22:48:17 UTC, H. S. Teoh wrote:
On Mon, Jan 17, 2022 at 10:35:30PM +, forkit via
Digitalmars-d-learn wrote:
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
> [...]
[...]
If I were able to write a compiler, my compiler would warn you:
"This is il
On Mon, Jan 17, 2022 at 10:35:30PM +, forkit via Digitalmars-d-learn wrote:
> On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
> >
> > If I ever needed to foreach over 1-based indices, I'd write it this
> > way in order to avoid all confusion:
> >
> > foreach (i; 1 .. 5 + 1)
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
If I ever needed to foreach over 1-based indices, I'd write it
this way in order to avoid all confusion:
foreach (i; 1 .. 5 + 1)
{
}
This will immediately make whoever reads the code (i.e., myself
after 2
On Mon, Jan 17, 2022 at 10:22:19PM +, forkit via Digitalmars-d-learn wrote:
[...]
> I think it's fair to say, that I'm familiar with 0-based indexing ;-)
>
> my concern was with the 1..5 itself.
>
> In terms of what makes sense, it actually makes more sense not to use
> it, at all ;-)
If I e
On Monday, 17 January 2022 at 22:06:47 UTC, H. S. Teoh wrote:
Basically,
foreach (i; a .. b)
is equivalent to:
for (auto i = a; i < b; i++)
Just think of that way and it will make sense.
I think it's fair to say, that I'm familiar with 0-based indexing
;-)
my concern wa
On Mon, Jan 17, 2022 at 09:37:31PM +, forkit via Digitalmars-d-learn wrote:
> On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
> >
> > This kind of half-open interval, which includes the lower bound but
> > excludes the upper bound, is used in programming because it lets you
> >
On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
This kind of half-open interval, which includes the lower bound
but excludes the upper bound, is used in programming because it
lets you write
foreach (i; 0 .. array.length) writef("%s ", array[i]);
...without going past the
On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
On Monday, 17 January 2022 at 10:24:06 UTC, forkit wrote:
Edsger W. Dijkstra, a well-known academic computer scientist,
has written in more detail about the advantages of this kind of
interval:
https://www.cs.utexas.edu/users/EWD/t
On Monday, 17 January 2022 at 10:24:06 UTC, forkit wrote:
so I'm wondering why the code below prints:
1 2 3 4
and not
1 2 3 4 5
as I would expect.
foreach (value; 1..5) writef("%s ", value);
This kind of half-open interval, which includes the lower bound
but excludes the upper bound, is u
so I'm wondering why the code below prints:
1 2 3 4
and not
1 2 3 4 5
as I would expect.
foreach (value; 1..5) writef("%s ", value);
also, why is this not possible:
int[] arr = 1..5.array;
27 matches
Mail list logo
