On Wednesday, 17 May 2023 at 08:00:17 UTC, Dom DiSc wrote:
If you want auto-conversion, you should be more explicit:
```d
float opCast() { }
```
because if you return "auto" it is not the highest-prio fit and
therefore not chosen.
If you have multiple choices, you still don't need to use
"auto"
On Friday, 12 May 2023 at 15:00:48 UTC, Salih Dincer wrote:
```d
struct Fraction {
int num, den;
this(int n, int d)
{
num = n;
den = d;
}
// Cast Expression : convert float value of fraction
auto opCast(T : float)(
On Sunday, 7 May 2023 at 21:04:05 UTC, Inkrementator wrote:
Open question to everybody: What you're opinion on using opCast
for this? Since it's a type conversion, it seems fitting to me.
Can't converting without explicitly specifying in D is a big
shortcoming in my opinion. There is such a th
On Wed, May 10, 2023 at 10:57:13PM +, Chris Piker via Digitalmars-d-learn
wrote:
> On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote:
> > On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via
> > Digitalmars-d-learn wrote: [...]
> > I also suffer from left/right confusion, and al
On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote:
On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via
Digitalmars-d-learn wrote: [...]
I also suffer from left/right confusion, and always have to
pause to think about which is the right(!) word before uttering
it.
Oh, I though wa
On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via Digitalmars-d-learn
wrote:
[...]
> My problem with the terms lvalue and rvalue is much more basic, and is
> just a personal one that only affects probably 0.1% of people. I just
> can't keep left vs. right straight in real life. "Right" i
On Wednesday, 10 May 2023 at 16:01:40 UTC, H. S. Teoh wrote:
x = y;
^ ^
| |
lvalue rvalue
...
// This is OK:
x = y + 1;
// This is not OK:
(y + 1) = x;
Thanks for the clear explanation.
My problem with the ter
On Wed, May 10, 2023 at 03:24:48PM +, Chris Piker via Digitalmars-d-learn
wrote:
[...]
> It's off topic, but I forget why managing memory for rvalues* was
> pushed onto the programmer and not handled by the compiler. I'm sure
> there is a good reason but it does seem like a symmetry breaking
On Wednesday, 10 May 2023 at 14:42:50 UTC, Inkrementator wrote:
On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote:
https://gist.github.com/run-dlang/9b7aec72710b1108fc8277789776962a
Thanks for posting that. Reading over the code I'm reminded that
I never cared whether something was an
On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote:
On the other hand, your first suggestion of using opCast() does
seem like a reasonable choice to me. Can you provide a short
code snippet using opCast to achieve the same result?
I've never used it, and particularly I know that I don't
On 5/7/23 13:44, Chris Piker wrote:
> to fix the problem I
> just delete the alias this line from dpq2, see what unit tests and app
> code it breaks, then fix each of those.
Yes but I neglected the lvalue/rvalue issue. In some cases the code
won't compile if the return typ
On Sunday, 7 May 2023 at 21:04:05 UTC, Inkrementator wrote:
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
alias this is for implicit type conversions, which can be
achieved explicitly as well.
Open question to everybody: What you're opinion on using opCast
for this? Since i
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
alias this is for implicit type conversions, which can be
achieved explicitly as well.
Open question to everybody: What you're opinion on using opCast
for this? Since it's a type conversion, it seems fitting to me.
A
On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
auto main() {
auto c = new C();
// The same type conversion is now explicit:
foo(c.asIntPtr);
}
Hi Ali
Ah, very clear explanation, thanks! So basically to fix the
problem I just delete the alias this line from dpq2, see
On 5/7/23 10:55, Chris Piker wrote:
> According to dmd 2.103, alias this is
> deprecated for classes, so I'd like to correct the problem.
alias this is for implicit type conversions, which can be achieved
explicitly as well. Given the following old code:
class C {
int* result;
Hi D
One of the dependencies for my project has a class that makes use
of the `alias x this` construct. According to dmd 2.103, alias
this is deprecated for classes, so I'd like to correct the
problem.
Is there a specific paragraph or two that I can read to find out
what i
On Tuesday, 1 November 2022 at 23:01:57 UTC, Per Nordlöw wrote:
When is it preferrable to use
```d
struct S { private T t; alias t this; }
```
instead of
```d
struct S { public T t; alias t this; }
```
for any given type `T`?
If the `alias this` needs to work outside the module where `S
When is it preferrable to use
```d
struct S { private T t; alias t this; }
```
instead of
```d
struct S { public T t; alias t this; }
```
for any given type `T`?
On Tuesday, 12 October 2021 at 15:55:40 UTC, Johann Lermer wrote:
Thanks, understood. But isn't this a deficiency in the library
that should be fixed?
The problem extends to more than just `toHash`. Take a look at
this DConf 2019 presentation by Eduard Staniloiu on ProtoObject
(as proposed by
On Tuesday, 12 October 2021 at 15:55:40 UTC, Johann Lermer wrote:
Thanks, understood. But isn't this a deficiency in the library
that should be fixed?
You mean the part about how `Object.toHash` doesn't work with
`const`? Yes, it is a deficiency in the library. The problem is,
it cannot be fi
Thanks, understood. But isn't this a deficiency in the library
that should be fixed?
On Tuesday, 12 October 2021 at 09:30:57 UTC, Johann Lermer wrote:
Hi all,
I have a problem with Tuples and struct templates that contain
an alias this:
```d
import std;
struct Element(T)
{
T payload;
alias payload this;
this (T p)
{
payload
Hi all,
I have a problem with Tuples and struct templates that contain an
alias this:
```d
import std;
struct Element(T)
{
T payload;
alias payload this;
this (T p)
{
payload = p;
}
}
class Item {}
void main ()
{
auto e
, that should solve my current problem. The reason for
having an alias this was that I had a C data type
(cairo_surface_t) that I transferred into a class and I'm using
the alias so that I don't need to rewrite the whole application
at once. Unfortunately I overlooked some code that res
On Wednesday, 25 August 2021 at 12:23:06 UTC, Adam D Ruppe wrote:
[snip]
That's a lot about alias this that I didn't know. Thanks.
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
Hi all,
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from
the aliased object to this. Then, why do lines 18 and 22
compile in the code below? And, btw
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from
the aliased object to this.
What it does is if "a SOMETHING b" doesn't compile, it
On Wednesday, 25 August 2021 at 12:11:01 UTC, Johann Lermer wrote:
```d
14 void main ()
15 {
16 auto ac = new Alias_Class;
17 Test_Struct ts = ac; // compiles
18 ac = ts; // compiles as well - why?
19
20 auto tc = new Test_Class;
21 ts = tc.ac; // compi
Hi all,
I have a little problem understanding alias this. I always
thought, that alias this only makes implicit conversions from the
aliased object to this. Then, why do lines 18 and 22 compile in
the code below? And, btw, line 22 crashes with a segmentation
fault.
```d
01 struct
default property can be another object altogether. The
best use case I can think of is a default collection for a
class such as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago s
best use case I can think of is a default collection for a
class such as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago so I cannot
comment for what's oftenly used; I just st
class such
as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago so I cannot
comment for what's oftenly used; I just stated that I was pointed
to alias this when I asked for def
So a field that will automatically be resolved to as part of the
behavior of generated toString methods.
That really isn't what alias this is used for commonly. I.e.
struct ValueReference {
private {
SomethingElse* impl;
}
bool isNull() { return im
On Sunday, 8 August 2021 at 00:57:47 UTC, Paul Backus wrote:
On Sunday, 8 August 2021 at 00:52:43 UTC, someone wrote:
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would
On Sunday, 8 August 2021 at 00:52:43 UTC, someone wrote:
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would you, I mean the community, think is it a good idea to
file a DI
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would you, I mean the community, think is it a good idea to
file a DIP to eventually get a new attribute to unambiguously
On Wednesday, 7 July 2021 at 17:10:01 UTC, Paul Backus wrote:
On Wednesday, 7 July 2021 at 16:20:29 UTC, realhet wrote:
int[] opIndex() { return array; }
Thx, I didn't know about this type of opSlice override. It works
nicely.
Now I have these choices:
- write [] everywhere to access
On Wednesday, 7 July 2021 at 16:20:29 UTC, realhet wrote:
Hi,
I wanted to make a container class that exposes its elements
using a simple "alias this", but getting weird errors:
I test with the std.algorithm.filter template function.
1. when I use "alias this" on a fun
Hi,
I wanted to make a container class that exposes its elements
using a simple "alias this", but getting weird errors:
I test with the std.algorithm.filter template function.
1. when I use "alias this" on a function that returns a slice,
making the internal array unre
On Thursday, 22 October 2020 at 21:55:59 UTC, Jack Applegame
wrote:
There is a funny feature (or bug) in the D language:
static alias this and static operator overloading.
For example
interface Foo {
static {
int value;
void opAssign(int v) { value = v; }
int get
On Thursday, 22 October 2020 at 21:55:59 UTC, Jack Applegame
wrote:
Now we can use type Foo as if it were an lvalue/rvalue:
Foo = 5;
int a = Foo;
int b = Foo + a;
Haha, that's pretty neat!
There is a funny feature (or bug) in the D language:
static alias this and static operator overloading.
For example
interface Foo {
static {
int value;
void opAssign(int v) { value = v; }
int get() { return value; }
alias get this;
}
}
Now we can use
On Tuesday, 18 August 2020 at 05:54:16 UTC, H. S. Teoh wrote:
Here's a working example:
Thank you, it works!
On Tue, Aug 18, 2020 at 05:34:58AM +, novice3 via Digitalmars-d-learn wrote:
[...]
> The problem is:
> if i use fmt.spec in overloaded toString(),
> when i get error "phobos/std/format.d(2243): Error: no property ip for
> type onlineapp.IpV4Address"
Here's a working example:
-
On Monday, 17 August 2020 at 14:43:27 UTC, H. S. Teoh wrote:
What you need is to create an overload of toString that takes a
FormatSpec parameter, so that you can decide what should be
output for which format spec. Something along these lines:
Sorry, i can't make it works.
I tried ti read for
On Mon, Aug 17, 2020 at 02:29:47PM +, novice3 via Digitalmars-d-learn wrote:
[...]
> ```
> struct IpV4Address
> {
> private uint ip;
> alias ip this;
>
> string toString()
> {
> import std.conv: to;
> return to!string((ip >>> 24) & 0xFF) ~ "." ~
>to!string((ip >>> 1
Hello.
I need subtype uint to store ipv4 address.
It should be like ordinary uint,
except conversion to string with %s format.
My try https://run.dlang.io/is/fwTc0H failed on last assert:
```
struct IpV4Address
{
private uint ip;
alias ip this;
string toString()
{
import std.conv:
On Tuesday, 7 July 2020 at 00:35:38 UTC, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
I used it for widget inheritance in my experimental code here,
https://github.com/aferust/noobgui/blob/master/s
On Tuesday, 7 July 2020 at 00:44:32 UTC, Marcone wrote:
On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
Is the following ex
On 7/6/20 5:44 PM, Marcone wrote:
On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias this. I
need an Easy example to understand Alias This.
Is the following example useful?
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias this. I
need an Easy example to understand Alias This.
Is the following example useful?
http://ddili.org/ders/d.en/alias_this.html
Ali
On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
Is the following example useful?
http://ddili.org/ders/d.en/alias_this.html
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
On Monday, 25 May 2020 at 01:35:47 UTC, Danni Coy wrote:
can anybody tell me why
struct S
{
int x;
alias x this;
}
void test()
{
S s;
s = 8; // this works
S s = 8 // but this does not?
}
On Monday, 25 May 2020 at 01:35:47 UTC, Danni Coy wrote:
s = 8; // this works
S s = 8 // but this does not?
}
alias this only applies if you already have an object.
Construction is too soon.
You can add a constructor to make that work though.
On 5/24/20 6:35 PM, Danni Coy wrote:> can anybody tell me why
>
> struct S
> {
> int x;
> alias x this;
> }
>
> void test()
> {
> S s;
> s = 8; // this works
> S s = 8 // but this does not?
> }
alias this is for implicit conver
can anybody tell me why
struct S
{
int x;
alias x this;
}
void test()
{
S s;
s = 8; // this works
S s = 8 // but this does not?
}
On Monday, 8 July 2019 at 23:01:49 UTC, ag0aep6g wrote:
On 08.07.19 23:55, aliak wrote:
[...]
`source.front` is a temporary `Grapheme` and you're calling
`opSlice` on it. The documentation for `Grapheme.opSlice`
warns: "Invalidates when this Grapheme leaves the scope,
attempts to use it the
mory corruption." [1]
So you can't return `source.front[]` from your `front`. You'll have to
store the current `front` in your struct, I guess.
Also, returning a fresh range on every `alias this` call is asking for
trouble. This is an infinite loop:
auto u = "hello&quo
Problem 1:
I'm trying to get a string to behave as a .byGrapheme range by
default, but I can't figure out Grapheme. I'm trying to replicate
this behavior:
foreach (g; "hello".byGrapheme) {
write(g[]);
}
In a custom type:
struct ustring {
string data;
this(string data) {
On Monday, 6 May 2019 at 14:48:56 UTC, faissaloo wrote:
misunderstood how allocation works when instantiating a struct
that uses alias this:
alias this has no effect on allocation at all. All it does is if
x.y
doesn't compile, it rewrites it to
x.alias_this.y
(or if f(x) doesn'
On Monday, 6 May 2019 at 14:48:56 UTC, faissaloo wrote:
I've been having some memory issues (referenced objects turning
to nulls for no apparent reason) and I was wondering if I've
misunderstood how allocation works when instantiating a struct
that uses alias this:
import
On Monday, 6 May 2019 at 15:17:37 UTC, aliak wrote:
Do you have an example of a referenced object turning to null?
We may be able to spot something
Unfortunately I haven't managed to produce an example any smaller
than my entire codebase
On Monday, 6 May 2019 at 14:48:56 UTC, faissaloo wrote:
I've been having some memory issues (referenced objects turning
to nulls for no apparent reason) and I was wondering if I've
misunderstood how allocation works when instantiating a struct
that uses alias this:
import
I've been having some memory issues (referenced objects turning
to nulls for no apparent reason) and I was wondering if I've
misunderstood how allocation works when instantiating a struct
that uses alias this:
import std.stdio;
struct Parent {
; of this, you can't stop it
when it really doesn't make sense (as in this case).
Sure. At first I was perplexed why Dennis' a /= 2 even compiled.
Then I saw the alias this.
I have long wanted a way to direct IFTI how to define its
parameters base on the arguments. We have a simpl
On Monday, 19 November 2018 at 14:04:29 UTC, Dennis wrote:
On Monday, 19 November 2018 at 13:34:50 UTC, Stanislav Blinov
wrote:
Because it's not mutation, it's initialization.
Oh. That's an epiphany for me.
:)
When a ctor is `pure`, the compiler knows it doesn't mutate
any state other
On 11/18/18 1:17 PM, Stanislav Blinov wrote:
On Sunday, 18 November 2018 at 17:30:18 UTC, Dennis wrote:
I'm making a fixed point numeric type and want it to work correctly
with const. First problem:
```
const q16 a = 6;
a /= 2; // compiles! despite `a` being const.
Ouch. That's actu
On Monday, 19 November 2018 at 13:34:50 UTC, Stanislav Blinov
wrote:
Because it's not mutation, it's initialization.
Oh. That's an epiphany for me.
When a ctor is `pure`, the compiler knows it doesn't mutate any
state other than the object's, so it allows conversion to all
three qualifie
On Monday, 19 November 2018 at 12:28:43 UTC, Dennis wrote:
On Monday, 19 November 2018 at 02:39:32 UTC, Stanislav Blinov
wrote:
You're skimming the examples ;)
I'm not saying your examples don't work, I'm trying to
understand the minimum requirements. You said:
"That's [constructors needing
On Monday, 19 November 2018 at 02:39:32 UTC, Stanislav Blinov
wrote:
You're skimming the examples ;)
I'm not saying your examples don't work, I'm trying to understand
the minimum requirements. You said:
"That's [constructors needing to be pure is] only for types with
indirections (pointers)
On Monday, 19 November 2018 at 02:08:14 UTC, Dennis wrote:
On Monday, 19 November 2018 at 01:24:02 UTC, Stanislav Blinov
wrote:
Yup, that's because, like Rubn said, copying value types is
trivial. Where it all comes to bite you is when you start
having pointers, because you can't copy a const(T
On Monday, 19 November 2018 at 02:03:18 UTC, Dennis wrote:
On Monday, 19 November 2018 at 01:13:29 UTC, Stanislav Blinov
wrote:
You just dismissed that second to last sentence, did you? :)
I don't know what you mean with it. It's not that I'm trying to
be sneaky or lazy really trying to modif
On Monday, 19 November 2018 at 01:24:02 UTC, Stanislav Blinov
wrote:
Yup, that's because, like Rubn said, copying value types is
trivial. Where it all comes to bite you is when you start
having pointers, because you can't copy a const(T)* into a T*.
I'm not using reference types, but still:
`
On Monday, 19 November 2018 at 01:13:29 UTC, Stanislav Blinov
wrote:
You just dismissed that second to last sentence, did you? :)
I don't know what you mean with it. It's not that I'm trying to
be sneaky or lazy really trying to modify the const parameter
when I should treat it properly. And
On Monday, 19 November 2018 at 00:50:28 UTC, Dennis wrote:
I'm also trying to make it work with immutable, and from BigInt
[2] I learned that constructors need to be `pure` for creating
immutable objects. (I don't know why.)
That's only for types with indirections (pointers), since `pure`
gu
On Sunday, 18 November 2018 at 20:10:52 UTC, Dennis wrote:
On Sunday, 18 November 2018 at 18:17:54 UTC, Stanislav Blinov
wrote:
Q log2(Q)(inout Q num) if (is(Q : q16) || is(Q : q32)) { /*
... */ }
Being able to jam mutable/const/immutable implementation in
one function like that should tell
On Sunday, 18 November 2018 at 22:30:52 UTC, Rubn wrote:
Yah most people tend to avoid const for this reason. It only
really works for basic types, if you have a "const int" you can
convert it to an "int" by copy. But if you have a type like
Vector!(const int) that won't work, you can't even co
On Sunday, 18 November 2018 at 17:30:18 UTC, Dennis wrote:
I'm making a fixed point numeric type and want it to work
correctly with const. First problem:
```
const q16 a = 6;
a /= 2; // compiles! despite `a` being const.
writeln(a); // still 6
a.toQ32 /= 2;// what's actually h
On Sunday, 18 November 2018 at 18:17:54 UTC, Stanislav Blinov
wrote:
// implement separate methods for
mutable/const/immutable
Thanks. I should have tried that, but I assumed it wouldn't work
since you can't overload on return-type only. However, the const
/ non-const makes it allowed
On Sunday, 18 November 2018 at 17:30:18 UTC, Dennis wrote:
I'm making a fixed point numeric type and want it to work
correctly with const. First problem:
```
const q16 a = 6;
a /= 2; // compiles! despite `a` being const.
Ouch. That's actually kind of nasty.
writeln(a); // stil
I'm making a fixed point numeric type and want it to work
correctly with const. First problem:
```
const q16 a = 6;
a /= 2; // compiles! despite `a` being const.
writeln(a); // still 6
a.toQ32 /= 2;// what's actually happening
```
My q16 type has an implicit conversion to q32
On Monday, 15 October 2018 at 06:16:34 UTC, Alex wrote:
On Monday, 15 October 2018 at 04:51:39 UTC, Sobaya wrote:
[...]
Removing constraint, but retaining specialization should be
enough, no?
Then, func is still a template, requiring the argument to be
convertible to an int. When S is passed
On Monday, 15 October 2018 at 04:51:39 UTC, Sobaya wrote:
void func(T : int)(T value) if (is(T == int)) {
}
struct S {
int x;
alias x this;
}
void main() {
func(S()); // error
}
In above code, 'func' can accept only int as its argument type,
so when 'S', which can be implicitly co
void func(T : int)(T value) if (is(T == int)) {
}
struct S {
int x;
alias x this;
}
void main() {
func(S()); // error
}
In above code, 'func' can accept only int as its argument type,
so when 'S', which can be implicitly convertible into int, is
passed on 'func', I expect S.x is p
On Friday, 7 September 2018 at 02:22:58 UTC, Domain wrote:
The following code fail to compile:
enum KeyMod : int
{
LCtrl = 1 << 0,
RCtrl = 1 << 1,
Ctrl = LCtrl | RCtrl,
}
struct Flags(E)
{
public:
BitFlags!(E, Yes.unsafe) flags;
alias flags this;
bool opDispatch(str
The following code fail to compile:
enum KeyMod : int
{
LCtrl = 1 << 0,
RCtrl = 1 << 1,
Ctrl = LCtrl | RCtrl,
}
struct Flags(E)
{
public:
BitFlags!(E, Yes.unsafe) flags;
alias flags this;
bool opDispatch(string name)() const
if (__traits(hasMember, E, name))
On Sunday, 29 July 2018 at 23:03:27 UTC, Johannes Loher wrote:
Yeah, I know that it possible to implement the template like
this, but that is not the point here. I would like to know why
it does not work the way I described it. To me it seems very
strange, that `S : T` has different semantics i
,
MockedType)().existingInstance(myMock);
/* ... */
}
```
The problem with this is that register has the signature
described above, i.e. register(T, S : T)() and that the mock
template from unit-threaded is actually implemented by a struct
which is "alias this"ed (how do you call that.
On Sunday, 29 July 2018 at 16:43:08 UTC, Johannes Loher wrote:
I have a question about template argument matching in
combination with implicit conversion and alias this. Consider
the following code:
interface SomeInterface
{
}
class SomeClass : SomeInterface
{
}
struct SomeStruct
I have a question about template argument matching in combination
with implicit conversion and alias this. Consider the following
code:
interface SomeInterface
{
}
class SomeClass : SomeInterface
{
}
struct SomeStruct
{
SomeClass someClass;
alias someClass this;
}
template
eated.
Alternatively I could just pass the function directly around
without all the weight of the class.
This led me to wonder if there is a way to combine the two
methods?
With D's alias this would it be possible to have the user code
treat the function as a delegate but define the functions
round
without all the weight of the class.
This led me to wonder if there is a way to combine the two
methods?
With D's alias this would it be possible to have the user code
treat the function as a delegate but define the functions
actually in a class without any restrictions?
import
On Wednesday, 4 April 2018 at 15:57:19 UTC, Simen Kjærås wrote:
On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm
wrote:
if (is(T == A) || is(T == B) || is(T == Enum))
if (is(T : Enum))
--
Simen
Ah! Thanks a lot!
On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm
wrote:
private template Mix()
{
this(Enum ee) { e = ee; }
Enum e;
alias this = e;
}
Oops, typo in the alias. Should be `alias e this`
On Wednesday, 4 April 2018 at 15:49:31 UTC, Vladimirs Nordholm
wrote:
if (is(T == A) || is(T == B) || is(T == Enum))
if (is(T : Enum))
--
Simen
Hello people from D-land.
Short question: Can get the type of a struct that has `alias this
= ` ?
See this example, where a struct is aliased to an enum:
enum Enum { one, two, three, fourtytwo }
private template Mix()
{
this(Enum ee) { e = ee; }
Enum e
s that built in types don't have "members" per
se, they have "magic". The built in properties don't count to
`hasMember`. You could probably do `if(__traits(compiles,
mixin("a." ~ member))` though.
I assume this should work because rules for alias th
On Tuesday, 20 February 2018 at 11:27:23 UTC, Alex wrote:
There is a related ticket,
https://issues.dlang.org/show_bug.cgi?id=6434
However, not exactly facing this question.
Should that ticket be marked as resolved? The issue is for alias
this to be considered before opDispatch but there were
hey have "magic". The built in properties don't count to
`hasMember`. You could probably do `if(__traits(compiles,
mixin("a." ~ member))` though.
I assume this should work because rules for alias this (as I
understand) are to basically try if there's a member name
1 - 100 of 421 matches
Mail list logo
