On Wednesday, 4 October 2023 at 08:11:12 UTC, Joel wrote:
What am I missing?
Splitter returns a forward range so you can't slice the result.
You can use take() and drop() instead. Also, converting a string
range to int[] doesn't seem to work, but I don't know if it
should. Here is a version
What am I missing?
```d
import std;
void main() {
struct DateRem {
Date date;
string rem;
string toString() const => text(date.toSimpleString, " ",
rem);
}
DateRem[] daterem;
data
.splitter('\n')
.filter!(l => l.length && l[0].isDigit)
the case that we couldn't sort all of this
out and come up with a clean set of rules that allowed
functions that infer their attributes to call the correct
function, but it does get pretty complicated, and it comes with
the serious downside that there's no guarantee that the
overloads even do
he case that we couldn't sort all of this out and come
up with a clean set of rules that allowed functions that infer their
attributes to call the correct function, but it does get pretty complicated,
and it comes with the serious downside that there's no guarantee that the
overloads even do something
On Monday, 31 July 2023 at 16:52:03 UTC, Dennis wrote:
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote:
Is there a reason it would be difficult to make this not
compile?
No, except that might result in code breakage.
The only way you could have code breakage is if you have
```
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote:
Is there a reason it would be difficult to make this not
compile?
No, except that might result in code breakage.
On Monday, 31 July 2023 at 10:55:44 UTC, Quirin Schroll wrote:
What am I missing here?
The duplicate definition check doesn't consider whether a
function is actually unambiguously callable (without e.g. traits
getOverloads), it only prevents creating the same linker symbol
multiple time. So
Apparently, functions can be overloaded solely distinguished by
attributes:
```d
void f(ref int x) pure { x = 1; }
void f(ref int x) { x = 2; static int s; ++s; }
```
I thought that, maybe, a `pure` context calls the `pure` function
and an impure context calls the impure function, but no:
On Thursday, 2 June 2022 at 01:49:32 UTC, Ruby The Roobster wrote:
On Thursday, 2 June 2022 at 01:29:39 UTC, Ruby The Roobster
wrote:
On Thursday, 2 June 2022 at 01:00:57 UTC, Ali Çehreli wrote:
On 6/1/22 17:36, Ruby The Roobster wrote:
> A stripped down version of some code I have:
Not much
On Thursday, 2 June 2022 at 01:29:39 UTC, Ruby The Roobster wrote:
On Thursday, 2 June 2022 at 01:00:57 UTC, Ali Çehreli wrote:
On 6/1/22 17:36, Ruby The Roobster wrote:
> A stripped down version of some code I have:
Not much experience here but I made two changes:
1) Added 'shared':
>
On Thursday, 2 June 2022 at 01:00:57 UTC, Ali Çehreli wrote:
On 6/1/22 17:36, Ruby The Roobster wrote:
> A stripped down version of some code I have:
Not much experience here but I made two changes:
1) Added 'shared':
> this(Complex!real num = Complex!real(0,0)) shared
> {
>
On 6/1/22 17:36, Ruby The Roobster wrote:
> A stripped down version of some code I have:
Not much experience here but I made two changes:
1) Added 'shared':
> this(Complex!real num = Complex!real(0,0)) shared
> {
> this.num = num;
> }
>
A stripped down version of some code I have:
```d
public import std.complex;
public interface Mtype
{
// ...
}
public class Number : Mtype
{
public:
this(Complex!real num = Complex!real(0,0))
{
this.num = num;
}
this(shared Complex!real num =
On 12/7/21 1:03 PM, Q. Schroll wrote:
On Tuesday, 7 December 2021 at 12:43:40 UTC, Rumbu wrote:
Bug or feature?
Feature. It even has a name: "overload set". It keeps you from
accidentally calling a function you had no idea existed, for example
because of a name clash.
Not in this case.
On Tuesday, 7 December 2021 at 12:43:40 UTC, Rumbu wrote:
Bug or feature?
Feature. It even has a name: "overload set". It keeps you from
accidentally calling a function you had no idea existed, for
example because of a name clash.
Is there any workaround?
Yes, the error message is very
On 12/7/21 7:43 AM, Rumbu wrote:
On Friday, 3 December 2021 at 10:57:34 UTC, Stanislav Blinov wrote:
On Friday, 3 December 2021 at 10:42:37 UTC, Rumbu wrote:
Bug or feature? Is there any workaround?
The error message explains what to do :)
Error: class `mixinover.AnotherVisitor` use of
On Friday, 3 December 2021 at 10:57:34 UTC, Stanislav Blinov
wrote:
On Friday, 3 December 2021 at 10:42:37 UTC, Rumbu wrote:
Bug or feature? Is there any workaround?
The error message explains what to do :)
Error: class `mixinover.AnotherVisitor` use of
`mixinover.Visitor.visit(S s)` is
On Friday, 3 December 2021 at 10:42:37 UTC, Rumbu wrote:
Bug or feature? Is there any workaround?
The error message explains what to do :)
Error: class `mixinover.AnotherVisitor` use of
`mixinover.Visitor.visit(S s)` is hidden by `AnotherVisitor`;
use `alias visit = Visitor.visit;` to
```d
class S {}
class A:S {}
class B:S {}
mixin template vmix(T)
{
void visit(T t) {}
}
class Visitor
{
void visit(S s) {}
mixin vmix!A;
mixin vmix!B;
}
class AnotherVisitor: Visitor
{
override void visit(A a) {}
}
```
This will result in error when I try to override mixin
On Sunday, 5 September 2021 at 21:25:06 UTC, jfondren wrote:
On Sunday, 5 September 2021 at 20:49:08 UTC, james.p.leblanc
wrote:
Here's a reduction of your myArray.d that works with your
unchanged usage code:
```d
module myArray;
import std.stdio;
void opOpAssign(string op)(myArray
On Sunday, 5 September 2021 at 20:49:08 UTC, james.p.leblanc
wrote:
On Sunday, 5 September 2021 at 20:38:29 UTC, Paul Backus wrote:
Please post the source code for `myarray_mod` so that we can
reproduce the errors you're seeing.
Hello Paul,
Thanks for having a look ...
James
Here's a
On Sunday, 5 September 2021 at 21:06:49 UTC, Ali Çehreli wrote:
On 9/5/21 12:43 PM, james.p.leblanc wrote:
m[4 .. $] -= 100;
writeln(m);
m[] *= 2;
writeln(m);
}
Ali
Ali,
Thanks for your example code ... I have much to learn from this
and will need to study it tomorrow when I am
On 9/5/21 12:43 PM, james.p.leblanc wrote:
> I have constructed a custom array type that works, but is missing
> correct functioning on some operator overloads.
With its old, new, and newest styles; and support for multi-dimensional
use cases; operator overloading can be difficult to get
On Sunday, 5 September 2021 at 20:38:29 UTC, Paul Backus wrote:
On Sunday, 5 September 2021 at 19:43:20 UTC, james.p.leblanc
wrote:
Dear D-ers,
I have constructed a custom array type that works, but is
missing
correct functioning on some operator overloads.
[...]
```d
import std.stdio
On Sunday, 5 September 2021 at 19:43:20 UTC, james.p.leblanc
wrote:
Dear D-ers,
I have constructed a custom array type that works, but is
missing
correct functioning on some operator overloads.
[...]
```d
import std.stdio;
import myarray_mod;
```
Please post the source code
Dear D-ers,
I have constructed a custom array type that works, but is missing
correct functioning on some operator overloads.
The stripped down minimum example (module) was over 100 lines (due
overloading opAssign, etc.) Probably too long to be a good forum
post.
However, a short main may
I have a struct where I use a number of
"invariant(){enforce( blah, blah ...);}"
statements in the struct body to enforce certain
conditions on a struct member.
Since these "invariants" are only called when struct member
functions are exercised, must I overload each
individual
On Sunday, 30 May 2021 at 18:50:25 UTC, Adam D. Ruppe wrote:
On Sunday, 30 May 2021 at 18:42:34 UTC, data pulverizer wrote:
I wonder if it is a purposeful design
It is by design: https://dlang.org/articles/hijack.html
Basically the idea behind it is to make sure that a change in a
lib you
On Sunday, 30 May 2021 at 18:42:34 UTC, data pulverizer wrote:
I wonder if it is a purposeful design
It is by design: https://dlang.org/articles/hijack.html
Basically the idea behind it is to make sure that a change in a
lib you import doesn't change your existing code without you
realizing
Hi,
There's issue in importing functions I came across some time ago
that I wonder if it is a purposeful design or if it is something
that will be changed in the future.
Say I have module like this:
```d
module funs;
double myfun(double x)
{
return x*x;
}
```
and I call `myfun` in a
On Tuesday, 4 May 2021 at 11:21:20 UTC, Zone wrote:
```D
template Vectorize_Unary_Function(alias fun) {
float[N] Vectorize_Unary_Function(size_t N)(float[N] vec)
{
float[N] result;
static foreach (i; 0 .. N)
result[i] = fun(vec[i]);
return result;
On Tuesday, 4 May 2021 at 11:00:42 UTC, Blatnik wrote:
I'm porting over my linear algebra library from C++, and I have
a bunch of functions that work on both scalars and vectors. The
vector versions just apply the scalar function to every element
of the vector, for example:
```D
float
On Tuesday, 4 May 2021 at 11:00:42 UTC, Blatnik wrote:
How could I do this?
I've already tried this:
```D
mixin template Vectorize_Unary_Function(alias Function)
{
float[N] Function(size_t N)(float[N] vec)
{
float[N] result;
static foreach (i; 0 .. N)
result[i] =
I'm porting over my linear algebra library from C++, and I have a
bunch of functions that work on both scalars and vectors. The
vector versions just apply the scalar function to every element
of the vector, for example:
```D
float clamp01(float x) { return x < 0 ? 0 : (x > 1 ? 1 : x); }
On 5/18/20 9:18 PM, Ali Çehreli wrote:
On 5/18/20 1:11 PM, BoQsc wrote:> I'm trying to kill my own process, but
I'm being unsuccessful at the
> compilation of the program. It seems that neither getpid nor
> thisProcessID returns a correct type value for the kill function.
Of course, Adam D.
On Monday, 18 May 2020 at 20:40:47 UTC, Adam D. Ruppe wrote:
On Monday, 18 May 2020 at 20:11:25 UTC, BoQsc wrote:
I'm trying to kill my own process
Don't kill yourself, just `return` from main.
Returning does what I need, however I still need to get a working
example on killing/terminating
On 5/18/20 1:11 PM, BoQsc wrote:> I'm trying to kill my own process, but
I'm being unsuccessful at the
> compilation of the program. It seems that neither getpid nor
> thisProcessID returns a correct type value for the kill function.
Of course, Adam D. Ruppe is right: You can simply return from
On Monday, 18 May 2020 at 20:11:25 UTC, BoQsc wrote:
I'm trying to kill my own process
Don't kill yourself, just `return` from main.
I'm trying to kill my own process, but I'm being unsuccessful at
the compilation of the program. It seems that neither getpid nor
thisProcessID returns a correct type value for the kill function.
HelloWorld.d(24): Error: none of the overloads of kill are
callable using argument types (int
On Tuesday, 9 July 2019 at 08:51:59 UTC, Mitacha wrote:
I've managed to make it work using 'alias this' and wrapper
struct.
https://run.dlang.io/is/3SMEFZ
It's not an elegant solution, there could be a better way to do
this.
Yea, a wrapper struct with custom `toString` seems the most
On Monday, 8 July 2019 at 12:53:18 UTC, Digital Mars wrote:
I guess that there is no way to have `writeln` automatically
use the output range overload instead of allocating one. You
need somehow to provide the output range to `toISOExtString`
explicitly because `writeln` outputs the return of
On Monday, 8 July 2019 at 12:53:18 UTC, Digital Mars wrote:
08.07.2019 13:38, Joseph Rushton Wakeling пишет:
[...]
Sorry that my answer wasn't thoughtful.
I guess that there is no way to have `writeln` automatically
use the output range overload instead of allocating one. You
need somehow
08.07.2019 13:38, Joseph Rushton Wakeling пишет:
Thanks for taking the time to answer, but I don't think this really
addresses my question.
Your example shows a struct with `toString` overloads. However,
SysTime.toISOExtString does not work like this: it is a method with two
explicit
is exactly how it is intended to work:
https://run.dlang.io/is/ATjAkx
Thanks for taking the time to answer, but I don't think this
really addresses my question.
Your example shows a struct with `toString` overloads. However,
SysTime.toISOExtString does not work like this: it is a method
07.07.2019 17:49, Joseph Rushton Wakeling пишет:
it's possible to do something like `writefln!"%s"(now.toISOExtString)` and have
it automatically use the output range overload rather than allocating a new string
instance.
This is exactly how it is intended to work:
Hello folks,
Is there an idiomatic/intended way to use the output-range taking
overloads of SysTime.toISOString and toISOExtString with stuff
like `writeln` and `format`, as opposed to explicitly generating
an output range to stdout or a string, and passing that to these
methods?
I'm a bit
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.
exactly what I did. Initially I did pass just T,
since I was working with types, but that quickly failed and I
switch all the reflects to alias T. That then failed though
because I couldn't pass certain things. I initially used
overloads to handle it but that caused problems, I then switched
to using
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:
"string")]
Signature = int()
NumArgs = 0
Linkage = D
ReturnType = int
Parameters = []
Overloads = [
Id = foo
TypeName =
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?
Uses = []
Attributes = [sAttributeReflection("A", "string")]
Signature = int()
NumArgs = 0
Linkage = D
ReturnType = int
Parameters = []
DType = delegate
On Monday, 11 September 2017 at 20:40:30 UTC, nkm1 wrote:
I don't know, maybe don't use alias this :) IMO, it's a really
dubious feature...
I don't think it's an issue of alias this, per se. I think it's
just something to be aware of and use your approach of aliasing
as necessary. It's
On Monday, 11 September 2017 at 18:15:36 UTC, jmh530 wrote:
An interesting example. I'm not sure overriding is the issue so
most as what is in the overload set. I think foo(int) is not
part of the overload set yet. The compiler is able to cast the
long to int and then call the one in class B
On Monday, 11 September 2017 at 17:59:25 UTC, nkm1 wrote:
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
I suppose my issue is that final should prevent function
hijacking because I shouldn't be allowed to override string
bar(double d) anyway. It shouldn't be a worry.
It has
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
I suppose my issue is that final should prevent function
hijacking because I shouldn't be allowed to override string
bar(double d) anyway. It shouldn't be a worry.
It has nothing to do with overriding. Consider:
import std.stdio;
On Monday, 11 September 2017 at 04:29:39 UTC, Ali Çehreli wrote:
Here, the feature called "name hiding" is in effect. Foo2.bar
hides all bars from Foo. This is to avoid "function
hijacking"[1].
Ali
[1] https://dlang.org/hijack.html
I suppose my issue is that final should prevent function
On 09/10/2017 08:14 PM, jmh530 wrote:
> In the code below, the second to the last line fails to compile. As far
> as I can tell it is because the override also overrides all overloads. I
> could imagine why it would occur with a virtual member function, but I
> would think
In the code below, the second to the last line fails to compile.
As far as I can tell it is because the override also overrides
all overloads. I could imagine why it would occur with a virtual
member function, but I would think it wouldn't be necessary with
a final one.
@system
unittest
On Tuesday, 27 September 2016 at 09:21:04 UTC, pineapple wrote:
I'd really like to define my own types that accept indexes for
opIndex and opSlice as template arguments. Is there any way to
do this? If not, this seems like an obvious thing to add to the
language - what's been holding it back?
I'd really like to define my own types that accept indexes for
opIndex and opSlice as template arguments. Is there any way to do
this? If not, this seems like an obvious thing to add to the
language - what's been holding it back?
On Wednesday, 21 September 2016 at 12:39:57 UTC, Johan Engelen
wrote:
It should really be mentioned in the documentation of
toHexString, with an actual example instead of a unittest.
Do you use my dpldocs.info? I add such notes there from time to
time:
On Wednesday, 21 September 2016 at 13:06:08 UTC, Adam D. Ruppe
wrote:
the variable you are assigning the result to never does
anything with regard to overloads or template args.
Gotcha, thanks.
to be but in any case,
you'd still need to specify T somewhere in the call, the variable
you are assigning the result to never does anything with regard
to overloads or template args.
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe
wrote:
This is a pretty common pitfall (and IMO one of the most
egregious design flaws in the language), I see it all the time.
I write very little D code, so I guess it had to happen at some
point then. Man, this is really bad
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe
wrote:
It is neither, the compiler chose the right overload (remember,
overloads are chosen based on the arguments alone, the type you
specify for the variable holding the return value isn't a
consideration
.
If you passed `hash[]` it should then do what you want... so
arguably the implicit slice rule is confusing you here too, I'd
LOVE to kill that rule entirely.
I don't know whether this is a compiler bug (choosing the wrong
overload) or a Phobos bug (overloads don't work like that).
It is neither
turn toHexString(hash);
```
the compiler errors with:
`Error: escaping reference to stack allocated value returned by
toHexString(hash)`.
So:
- the documentation of toHexString says that the overloads
returning a string return a GC allocated string
- the _implementation_ of `string toHexStr
On Thursday, 14 July 2016 at 00:02:25 UTC, pineapple wrote:
I was surprised when this didn't work. What's the rationale? Is
there any better workaround than renaming methods?
Looks like this:
http://dlang.org/hijack.html
Just add `alias foo = A.foo;` to B and it should work.
I was surprised when this didn't work. What's the rationale? Is
there any better workaround than renaming methods?
interface A{
void foo();
final void foo(int x){}
}
class B: A{
void foo(){}
}
void main(){
auto b = new B();
b.foo();
pointers to all public member functions and their overloads,
excluding template member functions. This is turning out to be
hard due to these "unexpected behaviors".
Is there anything else I can do?
__traits(getOverloads, x, Member).length works if you place the
template after a
d.
2. That alias breaks getProtection - is this bug? Seems like it
should be public.
These two make it quite hard to iterate over and collect info
about arbitrary aggregates.
I want to get a list of all *public* members, including pointers
to all public member functions and their overloads, exc
1 - 100 of 166 matches
Mail list logo
