On Sunday, 2 February 2020 at 23:48:45 UTC, Paul Backus wrote:
On Sunday, 2 February 2020 at 23:39:10 UTC, ShadoLight wrote:
But, my question was if this was avoidable if braces were not
optional. Paul's answer was that non-optional braces will not
make...
alias a = S!(int);
...
On Sunday, 2 February 2020 at 23:39:10 UTC, ShadoLight wrote:
But, my question was if this was avoidable if braces were not
optional. Paul's answer was that non-optional braces will not
make...
alias a = S!(int);
... non-ambiguous, but I still don't get that based on the
above results.
On Sunday, 2 February 2020 at 18:30:17 UTC, Steven Schveighoffer
wrote:
Thanks for taking the time to explain. However, when I tested my
results does not seem to match your explanation.
First, note that:
struct S(T) {}
is *exactly* equivalent to (in fact, you can write it this way,
and
On 2/2/20 12:51 PM, ShadoLight wrote:
// Should this assertion pass or fail?
static assert(is(a)); //PASS
static assert(is(b)); //FAIL
But I don't see how braces will affect this. Can you explain?
First, note that:
struct S(T) {}
is *exactly* equivalent to (in fact, you can write it this
On Sunday, 2 February 2020 at 16:23:42 UTC, Paul Backus wrote:
[..]
No, it would still be ambiguous:
struct S(T) {}
alias a = S!(int);
// Should this assertion pass or fail?
static assert(is(a));
Sorry, I don't get it. AFAICS 'is(a)' should return true (since a
is an alias for a full
On Sunday, 2 February 2020 at 13:01:26 UTC, ShadoLight wrote:
Not bad and definitely an improvement , but I still find the
inconsistency jarring... IIUC this 'ambiguity' would have been
avoidable if template argument braces were not optional, right?
No, it would still be ambiguous:
struct
On Friday, 31 January 2020 at 15:37:06 UTC, Steven Schveighoffer
wrote:
On 1/30/20 9:10 AM, ShadoLight wrote:
but to give you some historical perspective...
[..]
It was actually much more restrictive before -- e.g. in order
to do an eponymous template, you could have no other members
On 1/30/20 9:10 AM, ShadoLight wrote:
Why does the 'classical' template calling convention not work anymore in
this case? (if the template name and function name are different it
obviously still works). Note the templates were not defined in the
simplified 'Eponymous Trick' style i.e.:
I
On Thursday, 30 January 2020 at 20:42:02 UTC, Paul Backus wrote:
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
[..]
would make the language grammatically ambiguous...
OK, understood. Thank you.
On Thursday, 30 January 2020 at 20:00:05 UTC, MoonlightSentinel
wrote:
On Thursday, 30 January 2020 at 17:00:08 UTC, ShadoLight wrote:
[..]
...your proposed change it would be ambigous ...
Ok, that makes sense - I did not consider the impact of the
optional empty braces. Thank you.
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
Is there a technical reason for this limitation? Why are the
'classical' invocation style not allowed for eponymous
templates as well?
The 'classical' invocation style is not allowed because it would
make the language
On Thursday, 30 January 2020 at 17:00:08 UTC, ShadoLight wrote:
Agreed. My question though is should the 'shorthand' notation
_replace_ the 'longhand' notation, or be available _in
addition_ to the 'longhand' notation in the eponymous case (so
the eponymous notation is just 'syntax sugar' if
On Thursday, 30 January 2020 at 16:16:48 UTC, MoonlightSentinel
wrote:
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
[...]
From my POV is
void foo(T)() { ... }
just a shorthand notation for...
Agreed. My question though is should the 'shorthand' notation
_replace_ the
On Thursday, 30 January 2020 at 15:14:43 UTC, ShadoLight wrote:
Is there a technical reason for this limitation? Why are the
'classical' invocation style not allowed for eponymous
templates as well?
It seems somewhat arbitrary - note that inner/outer functions
does not have this limitation -
On Thursday, 30 January 2020 at 14:22:11 UTC, Paul Backus wrote:
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
...but in the 'classical' default template style, so I would
have thought the
template_name!(compile_time_args).function_name(run_time_args)
style would still work,
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
...but in the 'classical' default template style, so I would
have thought the
template_name!(compile_time_args).function_name(run_time_args)
style would still work, even if the template and function names
are identical.
If this
On Thursday, 30 January 2020 at 14:10:38 UTC, ShadoLight wrote:
Taking this example from documentation page on 'Template
Sequence Parameters' [1]:
[...]
Tested on https://run.dlang.io
Taking this example from documentation page on 'Template Sequence
Parameters' [1]:
import std.stdio;
template print(args...)
{
void print()
{
writeln("args are ", args); // args is a ValueSeq
}
}
template write(Args...)
{
void write(Args args) // Args is a TypeSeq
18 matches
Mail list logo
