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
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
Ahh, thanks a ton for these pointers, much appreciated!
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
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;
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
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
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
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
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
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
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
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
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
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
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.
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
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;
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.
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
20 matches
Mail list logo