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?
I
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 firs
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 co
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 sourc
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:
https://github.c
nswered.
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;
f
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;
}
retur
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 the
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 has
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 produce
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
> > gener
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 th
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,
> > long,
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 that
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 for the
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 sp
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
if(is(T:
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: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) {
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)) {
// D
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) {
// D
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 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 e
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 alw
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 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 on
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 more
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 t
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;
port. This also 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
On Tue, 22 Apr 2014 14:50:44 -0400, monarch_dodra
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
wrote:
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote:
Also, an immutable can be init
On Tuesday, 22 April 2014 at 18:35:58 UTC, Steven Schveighoffer
wrote:
On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra
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 e
On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra
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 immutable it would fail to
Am 22.04.2014 16:58, schrieb Andrej Mitrovic via Digitalmars-d-learn:
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
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...@
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(
>
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer
wrote:
On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra
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 immutab
On 4/22/14, Steven Schveighoffer via Digitalmars-d-learn
> I think this can be fixed a
different way.
Feel free to file a bug / make a pull. :>
On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra
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 don't believe it's possi
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.
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 Tue, 22 Apr 2014 10:58:41 -0400, Andrej Mitrovic via
Digitalmars-d-learn wrote:
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
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.di
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
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
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 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 Phob
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
respe
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
wrote:
Is there any difference between "is(typeof())" and
__traits(compiles, )?
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 cl
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud
wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
wrote:
Is there any difference between "is(typeof())" and
__traits(compiles, )?
I find the latter cleaner: its intent is more apparent. I use
is(typeof()) only for really
rong with it.
Well I wrote this, so I should explain :-)
I'm pretty sure at one time, using 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 Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
wrote:
> Is there any difference between "is(typeof())" and
> __traits(compiles, )?
I find the latter cleaner: its intent is more apparent. I use
is(typeof()) only for really testing for type existence.
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 cl
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 co
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 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 const
> 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 won
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 ar
template strip(T) if(is(T == delegate))
Typo should be stripped.
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))
{
a
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 n
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[] argv)
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 next
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
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 t
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 temp
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:
h
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
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.
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 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) opAdd()(Mas
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 afte
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
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 mass.Mass!(d
99 matches
Mail list logo