Re: Is it possible to return mutable and const range from a single method?

2022-08-22 Thread realhet via Digitalmars-d-learn
On Monday, 22 August 2022 at 19:35:11 UTC, Steven Schveighoffer wrote: It is possible to write the same function for both const and mutable overloads by using the `this` template parameter: I guess before the "inout", "this This" was the only way to do this. I must remember this, it's really u

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 17:40:59 UTC, Andrey Zherikov wrote: I'm providing a struct (`U` in examples above) with some API and I'm looking for this struct as an UDA (through `hasUDA`/`getUDAs`). And actually I already have a mix of member-functions and free-functions in my API so it's gonna

Re: Fixed-size OutBuffer that doesn't call .resize() automatically? (for database page buffers)

2022-08-22 Thread Gavin Ray via Digitalmars-d-learn
Ahh, thanks a ton for these pointers, much appreciated!

Re: Is it possible to return mutable and const range from a single method?

2022-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 8/22/22 12:36 PM, realhet wrote: Hello, I managed to make a universal getParent() function which can preserve constness. I also had success with inout functions that work with this inout getParent method. Is it possible to do something like this but for the allParents input range producer

Re: Is it possible to return mutable and const range from a single method?

2022-08-22 Thread Ali Çehreli via Digitalmars-d-learn
On 8/22/22 09:36, realhet wrote: > It gives the protection I was needed but is it possible to make this > prettier? > auto allParents(){ >struct ParentRange{ > A act; > @property bool empty() const{ return act is null; } > @property A front() { return act;

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 16:42:50 UTC, Paul Backus wrote: It's probably not worth completely changing your API design just to work around this issue. Also, even if you do this, it is still possible for a user to run into a same problem with a member function of one of their own types; for e

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Paul Backus via Digitalmars-d-learn
On Monday, 22 August 2022 at 16:19:06 UTC, Andrey Zherikov wrote: I have an impression that template function can be called without parenthesis if it doesn't have run-time parameters so `func!0` is the same as `func!0()`. Am I wrong? You're not wrong. This behavior is a special case in `typeof

Is it possible to return mutable and const range from a single method?

2022-08-22 Thread realhet via Digitalmars-d-learn
Hello, I managed to make a universal getParent() function which can preserve constness. I also had success with inout functions that work with this inout getParent method. Is it possible to do something like this but for the allParents input range producer method? In the const range implementa

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 8/22/22 12:19 PM, Andrey Zherikov wrote: On Monday, 22 August 2022 at 15:20:46 UTC, Paul Backus wrote: On Monday, 22 August 2022 at 14:43:24 UTC, Andrey Zherikov wrote: But the question is still opened: why is `typeof(U().func!0)` not the same as `typeof(U().func!0())`? Probably because if

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Paul Backus via Digitalmars-d-learn
On Monday, 22 August 2022 at 16:06:37 UTC, Andrey Zherikov wrote: On Monday, 22 August 2022 at 15:15:22 UTC, Paul Backus wrote: My first instinct is to say that this is the user's mistake. UDAs are not evaluated like normal expressions, and anyone using UDAs is going to have to learn that soone

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 15:20:46 UTC, Paul Backus wrote: On Monday, 22 August 2022 at 14:43:24 UTC, Andrey Zherikov wrote: But the question is still opened: why is `typeof(U().func!0)` not the same as `typeof(U().func!0())`? Probably because if it were the same, it would be completely im

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 15:15:22 UTC, Paul Backus wrote: My first instinct is to say that this is the user's mistake. UDAs are not evaluated like normal expressions, and anyone using UDAs is going to have to learn that sooner or later. My feeling was that UDA expression is just an express

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Paul Backus via Digitalmars-d-learn
On Monday, 22 August 2022 at 14:43:24 UTC, Andrey Zherikov wrote: But the question is still opened: why is `typeof(U().func!0)` not the same as `typeof(U().func!0())`? Probably because if it were the same, it would be completely impossible to introspect on the type of `U.func!0` directly. The

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Paul Backus via Digitalmars-d-learn
On Monday, 22 August 2022 at 14:42:10 UTC, Andrey Zherikov wrote: My situation is that user can write some UDA expression and I'm checking whether it's of a type `U` using `hasUDA!(sym, U)` and `getUDAs!(sym, U)`. Is the users uses `U()` or `U().func!0()`, everything works. But `U().func!0` doe

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
But the question is still opened: why is `typeof(U().func!0)` not the same as `typeof(U().func!0())`? There is also inconsistency within UFCS - type depends on whether function is a member or standalone (even if I replace `auto ref` with `ref U`): ```d struct U { ref U func(int i)() { ret

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 12:04:09 UTC, Paul Backus wrote: On Monday, 22 August 2022 at 11:24:59 UTC, Andrey Zherikov wrote: On Monday, 22 August 2022 at 06:01:11 UTC, JG wrote: Why not just change to: alias type = typeof(U().func!0()); This is user's code and `U().func!0` is legit syntax.

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 8/22/22 8:04 AM, Paul Backus wrote: On Monday, 22 August 2022 at 11:24:59 UTC, Andrey Zherikov wrote: On Monday, 22 August 2022 at 06:01:11 UTC, JG wrote: Why not just change to: alias type = typeof(U().func!0()); This is user's code and `U().func!0` is legit syntax. Workaround: wrap it

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Paul Backus via Digitalmars-d-learn
On Monday, 22 August 2022 at 11:24:59 UTC, Andrey Zherikov wrote: On Monday, 22 August 2022 at 06:01:11 UTC, JG wrote: Why not just change to: alias type = typeof(U().func!0()); This is user's code and `U().func!0` is legit syntax. Workaround: wrap it in a lambda. ```d import std.traits;

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 06:01:11 UTC, JG wrote: Why not just change to: alias type = typeof(U().func!0()); This is user's code and `U().func!0` is legit syntax.

Re: typeof(func!0) != typeof(func!0())

2022-08-22 Thread Andrey Zherikov via Digitalmars-d-learn
On Monday, 22 August 2022 at 05:25:50 UTC, Ali Çehreli wrote: This is where the @property keyword makes a difference: @property auto ref func(int i)() { return this; } Now U().func!0 will be a call in your expression. Is original `U().func!0` not a call? But I think std.traits.ReturnType