On Monday, 25 June 2018 at 18:59:37 UTC, Steven Schveighoffer
wrote:
On 6/25/18 2:51 PM, aliak wrote:
On Monday, 25 June 2018 at 15:06:42 UTC, Steven Schveighoffer
wrote:
I don't see any reason why the alias is to the function and
not the contexted function. I don't see how it's any
On 6/25/18 2:51 PM, aliak wrote:
On Monday, 25 June 2018 at 15:06:42 UTC, Steven Schveighoffer wrote:
I don't see any reason why the alias is to the function and not the
contexted function. I don't see how it's any different from the ones
which use inner functions.
I can only agree - me no
On Monday, 25 June 2018 at 15:06:42 UTC, Steven Schveighoffer
wrote:
On 6/24/18 5:19 PM, aliak wrote:
[...]
No, because the alias is an alias to the function, not the
delegate.
The act of taking the address creates the delegate, where the
delegate's ptr is the context pointer (i.e. s),
On 6/24/18 5:19 PM, aliak wrote:
Hi, I'm having some issues with template sequence parameters, it seems
they are not typed as delegates inside a template, but are outside. I.e.
template T(V...) {
alias T = typeof([0]);
}
struct S { void f() {} }
S s;
pragma(msg, T!(s.f)); // void
Hi, I'm having some issues with template sequence parameters, it
seems they are not typed as delegates inside a template, but are
outside. I.e.
template T(V...) {
alias T = typeof([0]);
}
struct S { void f() {} }
S s;
pragma(msg, T!(s.f)); // void function()
pragma(msg, typeof
On Monday, 22 June 2015 at 13:49:21 UTC, Steven Schveighoffer
wrote:
On 6/20/15 10:26 PM, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
On 6/22/15 1:37 PM, Yuxuan Shui wrote:
On Monday, 22 June 2015 at 13:49:21 UTC, Steven Schveighoffer wrote:
On 6/20/15 10:26 PM, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is
for template function
parameters
sadf.d(8): Error: template instance sadf.a!ulong.A!int error
instantiating
sadf.d(12):instantiated from here: ReturnTypeEx!(a, int)
sadf.d(8):instantiated from here: A!int
sadf.d(18):instantiated from here: ReturnTypeEx!(b, int)
sadf.d(18
On Sunday, 21 June 2015 at 02:37:59 UTC, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
understand.
But R is not a parameter on the function
On 6/20/15 10:26 PM, Yuxuan Shui wrote:
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't understand.
But R is not a parameter on the function itself. It comes from
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
understand.
But R is not a parameter on the function itself. It comes from
the outside template.
Move it to the inside template, rewrite it as:
auto a(S, R)(auto ref
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
understand.
But R is not a parameter on the function itself. It comes from
the outside template.
Move it to the
On Sunday, 21 June 2015 at 01:26:51 UTC, Adam D. Ruppe wrote:
On Saturday, 20 June 2015 at 01:50:11 UTC, Yuxuan Shui wrote:
auto ref R) is indeed a template function, so I don't
understand.
But R is not a parameter on the function itself. It comes from
the outside template.
Move it to the
) {
alias Ra = ReturnTypeEx!(R, S);
return cast(int)R!S(i);
}
}
void main() {
alias bb = b!(a!ulong);
pragma(msg, ReturnTypeEx!(bb, int));
}
DMD reports:
sadf.d(3): Error: auto can only be used for template function
parameters
sadf.d(8): Error: template
for template function
parameters
sadf.d(8): Error: template instance sadf.a!ulong.A!int error
instantiating
sadf.d(12):instantiated from here: ReturnTypeEx!(a, int)
sadf.d(8):instantiated from here: A!int
sadf.d(18):instantiated from here: ReturnTypeEx!(b, int)
sadf.d(18
On Monday, 18 May 2015 at 21:00:20 UTC, Per Nordlöw wrote:
Is this doable somehow?
To clarify: Instead of *string* `__FUNCTION__` I instead want a
reference to the *symbol* of the calling function scope typically
passed as an alias parameter. We could of course always solve it
with a mixin
As a follow up to the most
http://forum.dlang.org/thread/miri9k$2p5$1...@digitalmars.com
I'm now very much interested in finding a way to make yield()
capture the UDAs of its caller. That is instead of
void yield(T)(ref T value)
I want it to get a hold of the UDAs of the calling function
On Monday, 18 May 2015 at 21:35:44 UTC, Per Nordlöw wrote:
void yield(T)(ref T value)
{
mixin(alias caller = ~ caller ~ ;);
}
doesn't work across module boundaries not even for
`__PRETTY_FUNCTION__`.
Do we need need to fix the compiler, Walter?! ;)
You have to import
On Monday, 18 May 2015 at 21:04:19 UTC, Per Nordlöw wrote:
To clarify: Instead of *string* `__FUNCTION__` I instead want a
reference to the *symbol* of the calling function scope
typically passed as an alias parameter. We could of course
always solve it with a mixin but that is 6+1 characters
On Monday, 18 May 2015 at 21:30:23 UTC, Per Nordlöw wrote:
On Monday, 18 May 2015 at 21:04:19 UTC, Per Nordlöw wrote:
To clarify: Instead of *string* `__FUNCTION__` I instead want
a reference to the *symbol* of the calling function scope
typically passed as an alias parameter. We could of
not allow this syntax:
```
template (alias Modules ...) {
...
```
The grammar allows omitting the 'alias' keyword.
artur
alias parameters are different from normal template parameters. They're not
necessary for this problem, but they are for others.
I was trying to hint at the fact that D's
On Friday, 8 May 2015 at 02:03:17 UTC, Rikki Cattermole wrote:
Can you not use something like this?
Yes. I was getting confused by another problem that I had just
worked on before this one.
...) {
...
```
The grammar allows omitting the 'alias' keyword.
artur
alias parameters are different from normal template parameters.
They're not necessary for this problem, but they are for others.
As an example:
void traceVar(alias var, size_t line = __LINE__, string file =
__FILE__)()
{
import
On Friday, 8 May 2015 at 21:56:56 UTC, Brian Schott wrote:
Allowing template Tem(alias Args ...) syntax would let me
trace multiple variables at once.
Actually, this already works:
void traceVars(alias T, U...)() {
import std.stdio : writeln;
writeln(T.stringof, : , T);
static if
On Friday, 8 May 2015 at 22:29:28 UTC, Biotronic wrote:
Sadly, the ... syntax precludes the use of __LINE__ and
__FILE__. :(
You can put them in the runtime parameters:
void traceVars(alias T, U...)(size_t line = __LINE__, string file
= __FILE__) {
import std.stdio : writeln;
On 05/08/15 03:53, Brian Schott via Digitalmars-d-learn wrote:
The problem occurs when I want to register multiple modules to scan for
functions. The grammar does not allow this syntax:
```
template (alias Modules ...) {
...
```
The grammar allows omitting the 'alias' keyword.
artur
On 8/05/2015 1:53 p.m., Brian Schott wrote:
I have some code that automatically wires up control flow based on
annotations. Use of this code looks something like this:
```
import some_package.some_module;
void main(string[] args) {
doMagicStuff!(some_package.some_module)(args);
}
```
All
I have some code that automatically wires up control flow based
on annotations. Use of this code looks something like this:
```
import some_package.some_module;
void main(string[] args) {
doMagicStuff!(some_package.some_module)(args);
}
```
All of this works and everything is happy (Except
render3!(..., x, y);// ERROR
}
}
void main() {
import std.stdio;
int a, b;
render!(..., a, b)(s = write(s));
}
Inside the `render` function, which takes a string and several
variables as template parameters, as well as a delegate
Doesn't this cause infinite recursion?
On Sunday, 14 September 2014 at 09:29:16 UTC, Kagamin wrote:
Doesn't this cause infinite recursion?
No, because the inner templates are instantiated with different
first template parameters. Even if all template parameters were
the same, it would only be a runtime recursion.
On Mon, 18 Feb 2013 23:14:54 +0100, Andrej Mitrovic wrote:
http://dlang.org/template.html#TemplateThisParameter
That's hardly a descriptive example, so in what context is the feature
useful? Some code snippets would be welcome so we can update the page
with a nicer and more useful example.
On Mon, 18 Feb 2013 17:14:54 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
http://dlang.org/template.html#TemplateThisParameter
That's hardly a descriptive example, so in what context is the feature
useful? Some code snippets would be welcome so we can update the page
with a nicer
On 2/19/13, Steven Schveighoffer schvei...@yahoo.com wrote:
// don't need to redefine addAll
Ah, that sheds a big light on this feature actually, thanks.
Hi,
I'm playing around with template alias parameters. At the moment I'm
considering the following simple code:
struct A
{};
struct B( T )
{
T t;
};
struct C( alias T )
{
T t;
};
void main()
{
B!A a;
C!A b;
}
What exactly is the difference between a and b? Both seem to do
enuhtac Wrote:
Hi,
I'm playing around with template alias parameters. At the moment I'm
considering the following simple code:
struct A
{};
struct B( T )
{
T t;
};
struct C( alias T )
{
T t;
};
void main()
{
B!A a;
C!A b;
}
What exactly
On 03/05/2011 04:02 AM, Peter Lundgren wrote:
I have a function that I think should look something like this:
MyStruct!T myFunc(T)(MyStruct!T x, ...) {
...
return MyStruct!T(...);
}
and the closest I can get to is:
T myFunc(T)(T x, ...) {
...
return T(...);
}
and missed the
actual problem. I was mixing template type and template value parameters. What I
really wanted was this:
MyStruct!v myFunc(string v)(MyStruct!v x, ...) {
...
return MyStruct!v(...);
}
I have a function that I think should look something like this:
MyStruct!T myFunc(T)(MyStruct!T x, ...) {
...
return MyStruct!T(...);
}
and the closest I can get to is:
T myFunc(T)(T x, ...) {
...
return T(...);
}
which works, but doesn't make clear the intended
Why do they exist and why does typeof(this) strip constness?
import std.stdio;
struct S
{
const void foo(this T)(int i)
{
writeln(typeid(T));
}
const void bar()
{
writeln(typeid(typeof(this)));
}
}
void main()
{
const(S) s;
(s).foo(1);
S s2;
Trass3r u...@known.com wrote:
Why do they exist and why does typeof(this) strip constness?
Template this parameters allow for covariant return types, that's about
all the use cases I've found for it. It seems like such a great thing,
almost doing automatic overriding of methods in subclasses
On Tue, 25 Jan 2011 10:44:23 -0500, Trass3r u...@known.com wrote:
Why do they exist
It tells you the exact type of this at the call site. For const struct
functions, this will tell you what the actual constness of the variable
is. For classes, this may give you the derived or base class
On Tue, 25 Jan 2011 10:58:18 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
That seems like a bug, but actually, I'd not trust typeid. typeid is
actually a runtime-defined TypeInfo class, which you are calling
toString on, which is not telling you exactly what the compiler thinks
Simen kjaeraas simen.kja...@gmail.com wrote:
Given an index structure like this:
struct Index( alias arr ) if ( is( typeof( arr ) t : U[], U ) ) {
private size_t idx;
@property pure nothrow size_t get( ) const {
return idx;
}
alias get this;
invariant( ) {
Given an index structure like this:
struct Index( alias arr ) if ( is( typeof( arr ) t : U[], U ) ) {
private size_t idx;
@property pure nothrow size_t get( ) const {
return idx;
}
alias get this;
invariant( ) {
assert( idx arr.length );
}
this(
45 matches
Mail list logo
