On Saturday, 6 May 2017 at 10:18:24 UTC, Seb wrote:
As no one pointed it out before, FYI there has been a previous
DIP (https://wiki.dlang.org/DIP66) on which the old dmd PR was
based on.
Glad you mentioned that!
On Thursday, 4 May 2017 at 14:09:49 UTC, Carl Sturtivant wrote:
Reasonable. I may eventually resort to this possibility, but
right now I am trying to force out the consequences of avoiding
this extra complexity. (And syntax, yes, noted.)
Not finished posting to this thread yet.
As no one
On Wednesday, 3 May 2017 at 19:52:46 UTC, Daniel N wrote:
On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:
On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant
wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
Even better, with alias for embedded
On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:
On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant
wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
Even better, with alias for embedded aliased-to-this structs
made working usefully, name management can be
On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
Even better, with alias for embedded aliased-to-this structs
made working usefully, name management can be done before
embedding the features, by having another layer
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Image using frameworks which conveniently allow adding features
to a struct...
struct Beholder
{
mixin
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer
wrote:
One thing we can do also is just use declaration order to
prioritize which alias this to use.
Presumably using declaration order as a means of prioritizing
which name wins was rejected as a design possibility in the case
On Friday, 28 April 2017 at 07:07:44 UTC, Daniel N wrote:
On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:
On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant
wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC,
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Schveighoffer wrote:
I think you can appreciate that this doesn't scale. Imagine a
case which has 2 or 3 optional
On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:
On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at
On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Schveighoffer wrote:
I think you can appreciate
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Schveighoffer wrote:
I think you can appreciate that this doesn't scale. Imagine a
case which has 2 or 3 optional
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Schveighoffer wrote:
I think you can appreciate that this doesn't scale. Imagine a
case which has 2 or 3 optional alias this items.
-Steve
Agreed, not manually, as it is
for
resolving overloads and such with the names they introduce. Any
multiple alias this solution should investigate any parallels
with that.
The suggestion for multiple alias this I postulate in the
original post in this thread is a clean way to avoid that
complexity. Here's a summary.
https
On 4/21/2017 5:17 AM, Andrei Alexandrescu wrote:
This is interesting, and would be timely to discuss before an implementation of
multiple alias this gets started. -- Andrei
mixin templates already have an established method for resolving overloads and
such with the names they introduce. Any
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven Schveighoffer
wrote:
I think you can appreciate that this doesn't scale. Imagine a
case which has 2 or 3 optional alias this items.
-Steve
Agreed, not manually, as it is exponential in the number of
conditions. But I think some template
On 4/24/17 12:52 PM, Carl Sturtivant wrote:
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:
I agree, I like how this solves the ambiguity problem nicely. However,
this disallows using introspection to declare multiple alias this
piecemeal. e.g.:
struct S(bool foo)
{
int
On Monday, 24 April 2017 at 16:52:49 UTC, Carl Sturtivant wrote:
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer
wrote:
I agree, I like how this solves the ambiguity problem nicely.
However, this disallows using introspection to declare
multiple alias this piecemeal. e.g.:
On Friday, 21 April 2017 at 14:51:42 UTC, Meta wrote:
auto x = top(1,2,3);
void takesMember1(member1) {}
void takesMember2(member2) {}
void takesMember3(member3) {}
static assert(__traits(compiles, { takesMember1(x); }));
//Passes
static assert(__traits(compiles, { takesMember2(x); }));
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer
wrote:
I agree, I like how this solves the ambiguity problem nicely.
However, this disallows using introspection to declare multiple
alias this piecemeal. e.g.:
struct S(bool foo)
{
int x;
alias x this;
static if(foo)
{
On Fri, Apr 21, 2017 at 08:32:55PM +, Stefan Koch via Digitalmars-d wrote:
> On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote:
[...]
> > https://github.com/dlang/dmd/pull/3998/files
> >
> > It's written against C++ DMD as it was in 2014 so it may not be
> > feasible anymore to easily port
On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote:
On Friday, 21 April 2017 at 16:21:57 UTC, H. S. Teoh wrote:
On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu
via Digitalmars-d wrote: [...]
This is interesting, and would be timely to discuss before an
implementation of
On Friday, 21 April 2017 at 16:21:57 UTC, H. S. Teoh wrote:
On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu
via Digitalmars-d wrote: [...]
This is interesting, and would be timely to discuss before an
implementation of multiple alias this gets started. -- Andrei
Whatever
On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
> This is interesting, and would be timely to discuss before an
> implementation of multiple alias this gets started. -- Andrei
Whatever happened to the almost-complete implementation of alias this
that
On Friday, 21 April 2017 at 15:30:14 UTC, jmh530 wrote:
alias m3, m2, m1 this;
I thought they were deprecating the comma operator.
That's not the comma operator.
On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant
wrote:
struct top
{
mem3 m3;
mem2 m2;
mem1 m1;
alias m3, m2, m1 this;
// ...
}
I thought they were deprecating the comma operator.
On 4/21/17 8:17 AM, Andrei Alexandrescu wrote:
On 04/20/2017 04:35 PM, Carl Sturtivant wrote:
On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote:
Imagine the existing single `alias this` is extended to provide such a
heierarchy of lookups. For example,
struct top
{
mem3
On Thursday, 20 April 2017 at 20:35:04 UTC, Carl Sturtivant wrote:
On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant
wrote:
Imagine the existing single `alias this` is extended to
provide such a heierarchy of lookups. For example,
struct top
{
mem3 m3;
mem2 m2;
mem1 m1;
On 04/20/2017 04:35 PM, Carl Sturtivant wrote:
On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote:
Imagine the existing single `alias this` is extended to provide such a
heierarchy of lookups. For example,
struct top
{
mem3 m3;
mem2 m2;
mem1 m1;
alias m3, m2, m1
On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant
wrote:
Imagine the existing single `alias this` is extended to provide
such a heierarchy of lookups. For example,
struct top
{
mem3 m3;
mem2 m2;
mem1 m1;
alias m3, m2, m1 this;
// ...
}
could be interpreted to
Currently only one `alias this` declaration is permitted, and the
documentation https://dlang.org/spec/class.html#AliasThis says
the following.
"Multiple AliasThis are allowed. For implicit conversions and
forwarded lookups, all AliasThis declarations are attempted; if
more than one
31 matches
Mail list logo