On Wed, Apr 10, 2019 at 11:05:27PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
> > I wonder if there are some interesting patterns of nesting is's?
> >
> > is(...is(...is(...)...)...)
>
> No, at least not like that. You'd get
On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
I wonder if there are some interesting patterns of nesting is's?
is(...is(...is(...)...)...)
No, at least not like that. You'd get nothing out of it, even if
you made it work.
But, I have in the past nested static ifs with different
On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote:
On Tue, Apr 09, 2019 at 08:49:17PM +, Alex via
Digitalmars-d-learn wrote:
On Tuesday, 9 April 2019 at 18:56:58 UTC, H. S. Teoh wrote:
[...]
My point has been and is that there is a better way that is
more natural. I make no
On Wednesday, 10 April 2019 at 02:19:42 UTC, Adam D. Ruppe wrote:
On Tuesday, 9 April 2019 at 20:45:18 UTC, Alex wrote:
On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote:
Have you considered writing a DIP?
No, because I expect it won't even be considered.
You won't pass review if you
On Wednesday, 10 April 2019 at 14:06:53 UTC, Adam D. Ruppe wrote:
On Wednesday, 10 April 2019 at 10:18:35 UTC, H. S. Teoh wrote:
[...]
There's a little bit weird about it, but it makes sense.
I used to find it hard to even remember how it works, but then
I had to describe it for the book
On Wednesday, 10 April 2019 at 10:18:35 UTC, H. S. Teoh wrote:
The functionality rocks, but the syntax is a horrendous
hairball of inconsistencies and design-by-chance.
There's a little bit weird about it, but it makes sense.
I used to find it hard to even remember how it works, but then I
On Wed, Apr 10, 2019 at 02:22:35AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote:
> > (And on a side note: don't even get me started on is(...)
> > expressions.)
>
> is expressions rock. And I betcha if we did do libraries for
Another couple ideas you might get some traction on are making
typeid() values be convertible back into typeof types iff CTFE.
That would let you use types as OOP class values in intermediate
structures while still turning them back into template args later.
Not sure just how realistic that
On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote:
(And on a side note: don't even get me started on is(...)
expressions.)
is expressions rock. And I betcha if we did do libraries for
them, it would eventually go full circle, with someone doing a
pattern-matching DSL that reinvents
On Tuesday, 9 April 2019 at 20:45:18 UTC, Alex wrote:
On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote:
Have you considered writing a DIP?
No, because I expect it won't even be considered.
You won't pass review if you don't show knowledge of the existing
language, but there's a lot of
On Tue, Apr 09, 2019 at 08:49:17PM +, Alex via Digitalmars-d-learn wrote:
> On Tuesday, 9 April 2019 at 18:56:58 UTC, H. S. Teoh wrote:
[...]
> My point has been and is that there is a better way that is more
> natural. I make no claims about anything else. It may be a cop out to
> say
On Tuesday, 9 April 2019 at 18:56:58 UTC, H. S. Teoh wrote:
On Tue, Apr 09, 2019 at 06:33:21PM +, Seb via
Digitalmars-d-learn wrote:
On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote:
> On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe
> wrote:
> > [...]
> I didn't say the
On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote:
On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote:
On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
[...]
I didn't say the language. The point with the language is that
it could have built in semantics to do reflection in a
On Tue, Apr 09, 2019 at 06:33:21PM +, Seb via Digitalmars-d-learn wrote:
> On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote:
> > On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
> > > [...]
> > I didn't say the language. The point with the language is that it
> > could have
On Tuesday, 9 April 2019 at 16:30:53 UTC, Alex wrote:
On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
[...]
I didn't say the language. The point with the language is that
it could have built in semantics to do reflection in a inform
way(__traits is somewhat uniform but messy
On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
On Tuesday, 9 April 2019 at 14:42:38 UTC, Alex wrote:
It basically proves my point that there are issues with D.
The language is fine in this case, it is a bug in the library.
I didn't say the language. The point with the
On Tuesday, 9 April 2019 at 14:42:38 UTC, Alex wrote:
It basically proves my point that there are issues with D.
The language is fine in this case, it is a bug in the library.
Though, I don't think the library can be fixed because the
language doesn't have facilities to express these things
On Monday, 8 April 2019 at 21:52:59 UTC, Adam D. Ruppe wrote:
On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
Error: variable
`std.traits.ParameterDefaults!(foo).Get!1u.Get` only
parameters or stack based variables can be `inout`
so i think that is a bug in the phobos library
see:
On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
Error: variable
`std.traits.ParameterDefaults!(foo).Get!1u.Get` only parameters
or stack based variables can be `inout`
so i think that is a bug in the phobos library
see:
On 4/8/2019 7:39 AM, Alex wrote:
My point is that you are going ape shit over using T.stringof, you posted no
I mean, half the shit in __traits looks like it could be in std.traits and there
Please tone down both the aggressiveness and the use of cuss words, and use
professional demeanor.
On Monday, 8 April 2019 at 12:26:28 UTC, Adam D. Ruppe wrote:
On Sunday, 7 April 2019 at 17:42:58 UTC, Alex wrote:
That is blatantly wrong. The code works EXACTLY the same way
with and without using stringof.
In some cases, yeah. In the general case, no.
Your import hack* is only there
On Sunday, 7 April 2019 at 17:42:58 UTC, Alex wrote:
That is blatantly wrong. The code works EXACTLY the same way
with and without using stringof.
In some cases, yeah. In the general case, no.
Your import hack* is only there because of stringof. Using the
local symbol, there is no need to
On Sunday, 7 April 2019 at 15:35:46 UTC, FeepingCreature wrote:
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
rules are meant to be broken.
No they're not! Almost by definition not!
More comprehensively, if you break a rule you take
responsibility for the outcome. You wanna use
On Sunday, 7 April 2019 at 15:26:47 UTC, Adam D. Ruppe wrote:
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
What you need to tell me is why using .stringof is bad. You
have simply conjured up a rule and are stating it but not
giving any reason why it is not a good idea to follow when,
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
rules are meant to be broken.
No they're not! Almost by definition not!
More comprehensively, if you break a rule you take responsibility
for the outcome. You wanna use stringof? "Don't use stringof for
that." "rules are meant to be
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
What you need to tell me is why using .stringof is bad. You
have simply conjured up a rule and are stating it but not
giving any reason why it is not a good idea to follow when, in
fact, not following can be shown to be beneficial.
You
On 4/6/19 11:47 PM, Alex wrote:
> What you need to tell me is why using .stringof is bad. You have simply
> conjured up a rule and are stating it but not giving any reason why it
> is not a good idea to follow when, in fact, not following can be shown
> to be beneficial.
I'm not Adam, but I've
On Saturday, 6 April 2019 at 13:03:31 UTC, Adam D. Ruppe wrote:
On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
static foreach (f; typeof(__traits(getOverloads, T, m)))
Why are you using typeof here?
I don't know, I want to say I copied that code from somewhere but
it might have
On Saturday, 6 April 2019 at 12:20:28 UTC, Alex wrote:
static foreach (f; typeof(__traits(getOverloads, T, m)))
Why are you using typeof here?
probably 90% of the mixins are of the form
mixin(`Protection = __traits(getProtection,
(`~T.stringof~`).`~name~`);`);
Try following this rule:
On Friday, 5 April 2019 at 15:38:18 UTC, Adam D. Ruppe wrote:
BTW `T.stringof` is usually a bug waiting to happen. You are
using mixin in a lot of places where you shouldn't be and this
is going to lead to name conflicts, import problems, and more.
Just use `T`.
If you need a member, use
BTW `T.stringof` is usually a bug waiting to happen. You are
using mixin in a lot of places where you shouldn't be and this is
going to lead to name conflicts, import problems, and more. Just
use `T`.
If you need a member, use __traits(getMember, T, "name").
On Friday, 5 April 2019 at 14:38:21 UTC, Alex wrote:
No one has a clue about this?
Your code has a lot of layers to unfold, but instead let me just
show you a working example and then maybe you can fix your own
code:
---
class A {
void foo(int a) {}
void foo(int b, int c)
No one has a clue about this?
33 matches
Mail list logo
