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
On Wednesday, 26 April 2017 at 20:19:19 UTC, Walter Bright wrote:
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
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
30 matches
Mail list logo
