On Wednesday, 12 May 2021 at 12:54:24 UTC, Per Nordlöw wrote:
I'm certain I've seen dmd be able to diagnose which
sub-expression of `isDumb` and `isInputRange` that evaluated to
false. Did I just dream this or is there a way? If there is a
way does this improvement still reside in a dmd PR?
Given
```d
import std.range.primitives : isInputRange;
enum isDumb(Args...) = (Args.length == 2 && Args.length == 3);
void f(Args...)(Args args)
if (isDumb!(Args))
{
}
void g(Arg)(Arg arg)
if (isInputRange!(Arg))
{
}
@safe pure unittest
{
f(2, 3);
g(2);
}
```
`dmd` diagnoses the
On Friday, November 1, 2019 11:23:42 AM MDT Ali Çehreli via Digitalmars-d-
learn wrote:
> On 11/01/2019 09:33 AM, Paul Backus wrote:
> > On Friday, 1 November 2019 at 15:29:24 UTC, Ali Çehreli wrote:
> >> Apparently, it's the version for static arrays. However, I don't think
> >> the template
On 11/01/2019 09:33 AM, Paul Backus wrote:
> On Friday, 1 November 2019 at 15:29:24 UTC, Ali Çehreli wrote:
>> Apparently, it's the version for static arrays. However, I don't think
>> the template constraint is doing anything there because if T matches a
>> static array (of the form U[n]), then
On Friday, 1 November 2019 at 15:29:24 UTC, Ali Çehreli wrote:
On 11/01/2019 04:09 AM, berni44 wrote:
> What I don't understand is the 4th version with two extra
parameters.
> Here the documentation lacks an explanation, what this is
good for.
I went to the documentation by clicking "View
On 11/01/2019 04:09 AM, berni44 wrote:
> What I don't understand is the 4th version with two extra parameters.
> Here the documentation lacks an explanation, what this is good for.
I went to the documentation by clicking "View source code" and scrolled
a bit and found this:
is answered.
At least I was confused by similar lines, when I was a beginner
and did not know much about template constraints. What I would
have needed to know at that time is, that template constraints
limit the situations, where the template can be used. Here for
example, this destroy template can only
On Friday, 1 November 2019 at 09:17:03 UTC, Dennis wrote:
Template constraints are not allowed before the signature in
the language, so it can be expected the documentation does not
swap that order.
On Thursday, 31 October 2019 at 13:34:35 UTC, Tobias Pankrath
wrote:
I was confused at first
Template constraints are not allowed before the signature in the
language, so it can be expected the documentation does not swap
that order.
On Thursday, 31 October 2019 at 13:34:35 UTC, Tobias Pankrath
wrote:
I was confused at first by the trailing
if (!is(T == struct) &&am
e.g. here: https://dlang.org/library/object/destroy.html
I was confused at first by the trailing
if (!is(T == struct) && !is(T == interface) && !is(T == class)
&& !__traits(isStaticArray, T));
after I somehow managed to completely parse that page without
recognizing all other constraints.
On Sunday, 8 July 2018 at 02:10:12 UTC, Simen Kjærås wrote:
Also, you should probably use CommonType!A for the type of
temp, since an int can't hold all the possible values of a long
or ulong (or even uint), and you'll thus get unexpected results
with large numbers.
--
Simen
I see, thanks,
On Sunday, 8 July 2018 at 00:52:41 UTC, Flaze07 wrote:
On Sunday, 8 July 2018 at 00:46:13 UTC, Flaze07 wrote:
I want to force the variadic templates's type to be of certain
types, I thought doing this would work
auto sum( A... )( A a ) if( isIntegral!( typeid( a[ 0 ] ) ) )
{
int temp;
On Sunday, 8 July 2018 at 00:46:13 UTC, Flaze07 wrote:
I want to force the variadic templates's type to be of certain
types, I thought doing this would work
auto sum( A... )( A a ) if( isIntegral!( typeid( a[ 0 ] ) ) )
{
int temp;
foreach( t ; a )
{
temp += t;
}
I want to force the variadic templates's type to be of certain
types, I thought doing this would work
auto sum( A... )( A a ) if( isIntegral!( typeid( a[ 0 ] ) ) )
{
int temp;
foreach( t ; a )
{
temp += t;
}
return temp;
}
but it gives out error
( note : I want all
On Thursday, 26 April 2018 at 15:06:49 UTC, sungal wrote:
I have this piece of code and I can't understand why the
`static if` conditionals are always false.
```
import std.digest.sha;
import std.file;
import std.stdio;
void main()
{
auto hash1 = produceHash!string("prova.d");
auto
I have this piece of code and I can't understand why the `static
if` conditionals are always false.
```
import std.digest.sha;
import std.file;
import std.stdio;
void main()
{
auto hash1 = produceHash!string("prova.d");
auto hash2 = produceHash!File(File("./prova.d"));
}
string
On Saturday, 24 February 2018 at 03:04:07 UTC, Adam D. Ruppe
wrote:
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
The constraint is just like static if as to what it allows
On Saturday, February 24, 2018 04:33:52 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis
>
> wrote:
> > Why is there anything dodgy going on and why would you need
> > contracts? Contracts actually tend to go very badly with
> >
On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis
wrote:
Why is there anything dodgy going on and why would you need
contracts? Contracts actually tend to go very badly with
generic code, because whatever they assert has to be generic,
and while that works sometimes, more often
On Sat, Feb 24, 2018 at 02:54:13AM +, Jonathan via Digitalmars-d-learn
wrote:
> I am having trouble finding many useful explanations of using template
> constraints beyond basic usage.
>
> I would like to have a template constrant to enforce that a type can
> be explicitly
On Saturday, February 24, 2018 04:13:30 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis
>
> wrote:
> > Whether an implicit cast or an explicit cast makes more sense
> > depends entirely on what the code is doing, but either way, the
On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis
wrote:
Whether an implicit cast or an explicit cast makes more sense
depends entirely on what the code is doing, but either way, the
conversion needs to be forced inside the function, or you end
up with bugs. Far too often, when
On Saturday, February 24, 2018 03:48:44 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis
>
> wrote:
> > That does not do what the OP requested at all. That tests
> > whether T is one of byte, ubyte, short, ushort, int, uint,
> >
On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis
wrote:
That does not do what the OP requested at all. That tests
whether T is one of byte, ubyte, short, ushort, int, uint,
long, and ulong, whereas what the OP wants is to test whether T
can be cast to int.
- Jonathan M Davis
On Saturday, 24 February 2018 at 03:30:45 UTC, psychoticRabbit
wrote:
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce
On Saturday, February 24, 2018 03:30:45 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
>
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t
On Saturday, February 24, 2018 03:04:53 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
>
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
The constraint is just like static if as to what it allows
inside, so you can check almost anything in there.
Like
On Saturday, February 24, 2018 02:54:13 Jonathan via Digitalmars-d-learn
wrote:
> I am having trouble finding many useful explanations of using
> template constraints beyond basic usage.
>
> I would like to have a template constrant to enforce that a type
> can be explicitly cast
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a type
can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
On Thursday, 3 August 2017 at 12:49:48 UTC, data pulverizer wrote:
Hmm ... it looks as the specialization `:` operator is working
like the constraint `:` operator and doing convertible at least
for the floating point case. Is that right?
They're both doing the same thing as far as I know.
On Thursday, 3 August 2017 at 12:35:08 UTC, data pulverizer wrote:
What about this case:
```
T test(T: double)(T x, T y)
{
return x*y;
}
auto test(T)(T x, T y)
{
return 5*test!double(x, y);
}
```
which also gives:
```
int test: 4
double test: 4
```
Hmm ... it looks as the
On Thursday, 3 August 2017 at 12:31:00 UTC, Adam D. Ruppe wrote:
On Thursday, 3 August 2017 at 12:24:02 UTC, data pulverizer
wrote:
import std.traits: isIntegral, isNumeric;
Are you familiar with isFloatingPoint?
http://dpldocs.info/experimental-docs/std.traits.isFloatingPoint.html
On Thursday, 3 August 2017 at 12:24:02 UTC, data pulverizer wrote:
import std.traits: isIntegral, isNumeric;
Are you familiar with isFloatingPoint?
http://dpldocs.info/experimental-docs/std.traits.isFloatingPoint.html
if(is(T: double) && isNumeric!T)
Keep in mind that T:double here means
On Thursday, 3 August 2017 at 12:24:02 UTC, data pulverizer wrote:
The same issue occurs when I try using template specializations
instead. ...
That is T test(T: double)(T x, T y){...} and T test(T)(T x, T
y){...}
Thanks
Dear all,
I am writing template constraints for different numeric types:
```
import std.stdio: writeln;
import std.traits: isIntegral, isNumeric;
T test(T)(T x, T y)
if(is(T: double) && isNumeric!T)
{
return x*y;
}
auto test(T)(T x, T y)
if(!is(T: double) &&
On Wednesday, 7 September 2016 at 00:40:27 UTC, Jonathan M Davis
wrote:
On Tuesday, September 06, 2016 21:16:05 Jon Degenhardt via
Digitalmars-d-learn wrote:
On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
wrote:
> On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
>
On Tuesday, September 06, 2016 21:16:05 Jon Degenhardt via Digitalmars-d-learn
wrote:
> On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
>
> wrote:
> > On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
> >
> > wrote:
> >> Is there a way to constrain template arguments to
On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
wrote:
On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
wrote:
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ...
On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
wrote:
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ... }
--Jon
You can use `if(is(T : class) || is(T : interface))`.
If you
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ... }
--Jon
is it supposed to work?
normally it works e.g.
assert(0, "some\nstring");
prints:
some
string
but if you do it inside a template constraint like this:
void someTemp(T)(T t) if(isCallable!T.call!((b){assert(b,
"some\nstring");}))
{
}
it prints:
some\x0astring
On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:
Hi All,
Given this code:
---
import std.traits;
import std.range;
import std.stdio;
enum isSupportedRange(T) = (isInputRange!T &&
isIntegral!(ForeachType!T));
void func(T)(T vals)
{
static if(isSupportedRange!T) {
//
On Saturday, 24 October 2015 at 23:59:02 UTC, qsdfghjk wrote:
On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:
On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:
[...]
Oh and the workaround I'm using is this:
---
void func(T)(T vals) {
static if(isInputRange!T) {
On Saturday, 24 October 2015 at 23:59:02 UTC, qsdfghjk wrote:
On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:
On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:
[...]
Oh and the workaround I'm using is this:
---
void func(T)(T vals) {
static if(isInputRange!T) {
Hi All,
Given this code:
---
import std.traits;
import std.range;
import std.stdio;
enum isSupportedRange(T) = (isInputRange!T &&
isIntegral!(ForeachType!T));
void func(T)(T vals)
{
static if(isSupportedRange!T) {
// Do something with a range
} else {
// Do something
On Saturday, 24 October 2015 at 23:34:19 UTC, stewart wrote:
On Saturday, 24 October 2015 at 23:26:09 UTC, stewart wrote:
[...]
Oh and the workaround I'm using is this:
---
void func(T)(T vals) {
static if(isInputRange!T) {
static if(isIntegral!(ForeachType!T)) {
//
On Tuesday, 1 September 2015 at 15:50:40 UTC, jmh530 wrote:
I'm following some of your post, but not quite all of it
(particularly the part at the end, and I also think static
imports can't be selective). Anyway, I was thinking about
something like below as one possible alternative
struct T
On Tuesday, 1 September 2015 at 19:48:02 UTC, Enamex wrote:
They aren't selective, yeah. But the rationale is good: There's
not supposed to be any way to import modules with the same path
so static importing means it's entirely and always unambiguous.
I understand that a static import is
On Tuesday, 1 September 2015 at 21:17:10 UTC, jmh530 wrote:
Consider these three different ways to import std.stdio
import std.stdio;
import std.stdio : writeln;
static import std.stdio;
and suppose writeln is the only function in std.stdio the
program is using.
In each case, the size of the
On Monday, 31 August 2015 at 23:36:25 UTC, Enamex wrote:
I'm not sure whether a naked 'local.S' should work; sometimes
it does and sometimes it doesn't. But an `static import local;`
then `voidfoo(local.S)` definitely works.
`static import` forces the imported symbols to be fully
qualified
applies to template constraints I
think.
I put some code below to illustrate what I mean. The local import
has to apply to the entire app module in order for foo to work.
It can't only apply to the foo function the way that the
std.stdio import can. By contrast, bar uses a scoped import of S
(which
On Monday, 31 August 2015 at 19:10:45 UTC, jmh530 wrote:
module local;
struct S { int a = 2; }
module app;
import local : S;
void foo(S s)
{
import std.stdio : writeln;
writeln(s.a);
}
void bar()
{
import std.stdio : writeln;
import local : S;
S s;
On Monday, 31 August 2015 at 20:54:53 UTC, Enamex wrote:
You can't use it with foo(S) because the type is used /outside/
the scope of the function, in its head. You have to qualify it
( void foo(local.S s) ) or import the type as:
{ import local: S;
void foo(S s) { ... }
}
I figured
On Monday, 31 August 2015 at 21:22:07 UTC, jmh530 wrote:
I'm not sure about how the first local.S resolves things. I had
been using a selective import for S before. To get the local.S
to compile, I have to change the import to a normal one. I'm
concerned about the case where local contains
Hi there,
I recently read the 'More Templates' chapter of Ali's book (-- thanks
for that ;) ).
At the section 'Named constraints', there were a definition like this:
template isUsable(T)
{
enum isUsable = is ( typeof(
{
T obj;
obj.call();
obj.otherCall(1);
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
What does (inout int = 0) mean/affect here?
This was asked recently, see my reponse here:
http://forum.dlang.org/post/mailman.102.1396007039.25518.digitalmars-d-le...@puremagic.com
On Tue, 22 Apr 2014 10:58:41 -0400, Andrej Mitrovic via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
What does (inout int = 0) mean/affect here?
This was asked recently, see my
Not sure what InputRange is defined as atm, but I don't think
anything should have to define init to be a valid inputrange.
On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven Schveighoffer
wrote:
Note, is the r2 = R.init needed? Not sure.
Yes: It R2 has no default init, or is an immutable, then that
line will fail to compile.
On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven Schveighoffer wrote:
Note, is the r2 = R.init needed? Not sure.
Yes: It R2 has no default init, or is an immutable, then that line will
fail to compile.
I
On 4/22/14, Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com I think this can be fixed a
different way.
Feel free to file a bug / make a pull. :
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer
wrote:
On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra
monarchdo...@gmail.com wrote:
On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven
Schveighoffer wrote:
Note, is the r2 = R.init needed? Not sure.
Yes: It R2 has no default
On 04/22/2014 07:07 AM, Tim Holzschuh via Digitalmars-d-learn wrote:
read the 'More Templates' chapter of Ali's book (-- thanks
for that ;) ).
Yay! :)
At the section 'Named constraints', there were a definition like this:
template isUsable(T)
{
enum isUsable = is ( typeof(
{
Am 22.04.2014 16:58, schrieb Andrej Mitrovic via Digitalmars-d-learn:
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
What does (inout int = 0) mean/affect here?
This was asked recently, see my reponse here:
On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote:
Also, an immutable can be initialized that way:
immutable int[] = int[].init;
Isn't that exactly R.init ?
Yes, you said if it's an
On Tue, 22 Apr 2014 14:50:44 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Tuesday, 22 April 2014 at 18:35:58 UTC, Steven Schveighoffer wrote:
On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra
monarchdo...@gmail.com wrote:
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven
I'm trying to experiment a bit around the iota function.
If I try to impose the following constraits:
auto my_iota(B, E)(B begin, E end)
if (is (typeof(++begin)) is (typeof(begin end))) {}
Everything works as it should, but according to D Templates: A
Tutorial book, you should not use
fails to compile for both integers and my defined types.
I read the D Templates: A Tutorial book and as far as I can tell
++B.init and B.init E.init doesn't look too much wrong, but I've not
seen any constraint of this kind in phobos (using variables instead of
types) so I was wondering if
On Friday, 20 December 2013 at 15:38:56 UTC, Francesco Cattoglio
wrote:
I'm trying to experiment a bit around the iota function.
If I try to impose the following constraits:
Everything works as it should, but according to D Templates: A
Tutorial book, you should not use arguments in
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot cleaner.
On Friday, 20 December 2013 at 16:40:23 UTC, monarch_dodra wrote:
Everything works as it should, but according to D Templates:
A Tutorial book, you should not use arguments in constraints.
That's news to me.
It seems strange to me too, but: page 69 on the PDF:
Do not use argument in your
On Friday, 20 December 2013 at 17:18:01 UTC, Timon Gehr wrote:
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which
you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I find the latter cleaner: its intent is more apparent. I use
is(typeof()) only for really testing for type
direct symbols led to strange
behavior. And I'm still not sure symbol have values when used in
template constraints. What happens when you try ++a on such a symbol?
But then, if people tell me using these values directly is perfectly
OK, I'll update the text, of course.
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud
wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I find the latter cleaner: its intent is more
On Friday, 20 December 2013 at 17:18:01 UTC, Timon Gehr wrote:
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which
you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot
On 12/20/2013 09:42 PM, monarch_dodra wrote:
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I
On 12/20/2013 10:57 PM, Timon Gehr wrote:
Most non-trivial templates that use is(typeof(...)) in the constraint
can be broken. (In the sense that it is possible to instantiate them
even though their body does not compile.)
Actually, it seems that the behaviour of DMD has changed in this
On Friday, 20 December 2013 at 20:42:13 UTC, monarch_dodra wrote:
AFAIK, there is no real difference, but is(typeof()) is more
idiomatic in phobos.
Most uses of `is(typeof())` were written before the `compiles`
trait was introduced. Add the cargo cult to that, and it's no
wonder that Phobos
On 2013-12-14 23:38, DoctorCaptain wrote:
This is a very concise way to do what I want to do, but this check cares
about other attributes of the function/delegate, i.e. if the function or
delegate is designated as pure or nothrow and those don't show up in the
check, it will fail. As in:
auto
On Sunday, 15 December 2013 at 10:44:38 UTC, Jacob Carlborg wrote:
Hmm, there might be a way to strip all the attributes of a
function.
template strip(T) if(is(T == delegate))
{
alias stripped = ReturnType!T delegate(ParameterTypeTuple!T);
}
template strip(T) if(is(T == function))
{
template strip(T) if(is(T == delegate))
Typo should be stripped.
My question is hopefully short and straightforward to answer, but
it's also a two-parter.
I am working on a template that generates a function that
implements an algorithm using several helper functions that are
provided to the template by the user. I would like to add
constraints to the
On 12/14/2013 11:53 AM, DoctorCaptain wrote: My question is hopefully
short and straightforward to answer, but it's
also a two-parter.
I am working on a template that generates a function that implements an
algorithm using several helper functions that are provided to the
template by the
On 2013-12-14 20:53, DoctorCaptain wrote:
Second, can I get the level of thoroughness I am going for in these
constraints checks with fewer actual checks? As in, is there a more
straightforward way to do these checks without sacrificing any of them?
Thank you for any and all insight!
I would
Most uses of the 'is expression' allows using a specifier to
name the entity that matched. So, inserting ReturnedDelegate in
your '== delegate' line gives the name ReturnedDelegate to the
delegate.
That name can be used further:
template exT(T, alias nextGen)
if (
// Ensure
I have 3 comments (if you're still reading this thread :) )
First, you could let nextGen determine the return type. Since the
template know that nextGen returns an int delegate(int), there is no
need for the user to provide the 'int' parameter.
So user code could become:
void main(string[]
John:
Mass!(T,S) opAdd(Mass!(T,S) other) {
If you are using D2 then don't use opAdd, use opBinary:
http://dlang.org/operatoroverloading.html#Binary
Time ago I added an enhancement request for a warning (that later
is meant to become a deprecation) that helps avoid your problem:
I'm getting conflicting templates in this struct and I'm not sure
how. I specifically excluded the second definition of opAdd from
using type T in place of O but the compiler still tells me I'm
getting template conflicts.
Compiler error using Mass!(double,string):
Error: template
John:
Mass!(T,S) opAdd(Mass!(T,S) other) {
If you are using D2 then don't use opAdd, use opBinary:
http://dlang.org/operatoroverloading.html#Binary
Bye,
bearophile
On Tuesday, 2 July 2013 at 00:01:48 UTC, bearophile wrote:
John:
Mass!(T,S) opAdd(Mass!(T,S) other) {
If you are using D2 then don't use opAdd, use opBinary:
http://dlang.org/operatoroverloading.html#Binary
Bye,
bearophile
Thanks, I switched over to using the new function and
On Monday, 1 July 2013 at 23:36:27 UTC, John wrote:
struct Mass(T, S) {
...
Mass!(T,S) opAdd(Mass!(T,S) other) {
You can't overload non-templates with templates, yet. It's
supposed to work, but not implemented. The workaround is simple
enough:
Mass!(T,S)
John:
Mass!(T,S) opBinary(alias operator)(Mass!(T,S) other) {
Mass!(T,S) opBinary(alias operator, O)(Mass!(O,S) other) if
(!is(O == T)) {
Isn't operator better as string?
--
anonymous:
You can't overload non-templates with templates,
I think it was recently fixed in
On Tuesday, 2 July 2013 at 01:24:18 UTC, bearophile wrote:
anonymous:
You can't overload non-templates with templates,
I think it was recently fixed in Git.
It's still buggy then, since adding the empty parentheses makes
the error go away.
On Tuesday, 2 July 2013 at 01:39:22 UTC, anonymous wrote:
On Tuesday, 2 July 2013 at 01:24:18 UTC, bearophile wrote:
anonymous:
You can't overload non-templates with templates,
I think it was recently fixed in Git.
It's still buggy then, since adding the empty parentheses makes
the error
98 matches
Mail list logo
