On Monday, 31 July 2023 at 18:15:25 UTC, Jonathan M Davis wrote:
On Monday, July 31, 2023 4:55:44 AM MDT Quirin Schroll via
Digitalmars-d-learn wrote:
Apparently, functions can be overloaded solely distinguished by
attributes:
```d
void f(ref int x) pure { x = 1; }
void f(ref int x) { x
On Monday, July 31, 2023 4:55:44 AM MDT Quirin Schroll via Digitalmars-d-learn
wrote:
> 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; }
> ```
>
&g
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
Whenever there might be symbol clash, or when i want to make sure
i can identify where something from from i do:
```d
import me = my.awesome.module;
void main() {
me.hi();
}
```
On Friday, 28 July 2023 at 12:20:05 UTC, Steven Schveighoffer
wrote:
On 7/28/23 8:10 AM, Vijay Nayar wrote:
It might be possible to expand the grammar. It seems very
specific to UDAs, as it doesn't just throw out `Expression` or
whatnot. It probably has to do with the spot that it's in
On 7/28/23 8:10 AM, Vijay Nayar wrote:
However, this makes me wonder. Is there any reason why the `@` shouldn't
recognize the dots in a fully-qualified-name on its own, without the
need for parentheses?
It might be possible to expand the grammar. It seems very specific to
UDAs, as it doesn't
On Friday, 28 July 2023 at 11:54:12 UTC, Steven Schveighoffer
wrote:
On 7/28/23 4:15 AM, Vijay Nayar wrote:
I tried it and it worked for me. The template-argument syntax
is normal. It's just a list of types or expressions (i.e. not a
function argument list)
What is the error?
-Steve
On 7/28/23 4:15 AM, Vijay Nayar wrote:
On Thursday, 27 July 2023 at 21:24:44 UTC, Dennis wrote:
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in parenthesis.
```
static import vibe.data.serialization;
class
On Thursday, 27 July 2023 at 21:24:44 UTC, Dennis wrote:
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
@(vibe.data.serialization.name)("name")
...
}
```
Try:
```D
On Thursday, 27 July 2023 at 21:19:08 UTC, Vijay Nayar wrote:
Attempted Fix 2: Enclose the entire attribute name in
parenthesis.
```
static import vibe.data.serialization;
class ChatCompletionFunctions {
@(vibe.data.serialization.name)("name")
...
}
```
You almost had it. The correct
On Friday, 27 May 2022 at 09:41:32 UTC, user1234 wrote:
[...]
on a side note that's funny how dmd manages to systematically
print the less interesting message in both case.
They are actually correct, I dont know why at some point I
thought there was a problem. For the float one it's
On Friday, 27 May 2022 at 08:39:08 UTC, vit wrote:
Is in dmd some flag that print errors similarly to this?:
```d
void main()@safe pure{
foo!long();
foo!float();
//Error: `pure` function `D main` cannot call impure
function `onlineapp.foo!float.foo`
//Error:
foo!long();
foo!float(); //Error: `pure` function `D main` cannot call
impure function `onlineapp.foo!float.foo`
foo!int(); //Error: `@safe` function `D main` cannot call
`@system` function `onlineapp.foo!int.foo`
}
```
When template function foo is called and its inferred
attribu
On Friday, 27 May 2022 at 08:39:08 UTC, vit wrote:
Hello, I have this problem:
```d
static int i;
void bar(T)(){
static if(is(T == int))
(()@system => 1)();
static if(is(T == float))
i = 42;
}
void foo(T)(){
bar!T();
}
void main()@safe pure{
ain` cannot call
impure function `onlineapp.foo!float.foo`
foo!int(); //Error: `@safe` function `D main` cannot call
`@system` function `onlineapp.foo!int.foo`
}
```
When template function foo is called and its inferred attributes
are not compatible with attributes of main, errors are not rea
On Monday, 23 May 2022 at 13:53:02 UTC, Adam D Ruppe wrote:
On Monday, 23 May 2022 at 13:44:53 UTC, wjoe wrote:
[...]
You can actually make this work with `construct!(int[])` rather
than plain `construct`. This is a (really annoying) deficiency
in dmd's implementation. (that sdc solved
On Monday, 23 May 2022 at 13:44:53 UTC, wjoe wrote:
i.construct((ulong i) {return cast(int)(i+i);}).print;
You can actually make this work with `construct!(int[])` rather
than plain `construct`. This is a (really annoying) deficiency in
dmd's implementation. (that sdc solved btw proving it
Hello,
Consider this example:
```d
module foo;
import std.stdio;
import std.algorithm;
import std.traits;
import std.range;
void print(R)(R r) {
static assert(isIterable!R);
r.each!writeln;
}
auto construct(R)(R r, ElementType!R delegate(ulong i) fn) {
static assert(isIterable!R &&
On Thursday, 25 November 2021 at 12:16:50 UTC, rumbu wrote:
I try to base my reasoning on specification, dmd is not always
a good source of information, the lexer is polluted by old
features or right now by the ImportC feature, trying to lex D
an C in the same time.
Alright. I haven't looked
On Thursday, 25 November 2021 at 12:09:55 UTC, Dennis wrote:
This should also be fixed in the spec.
Filed as:
Issue 22543 - [spec] grammar blocks use unspecified notation:
https://issues.dlang.org/show_bug.cgi?id=22543
Issue 22544 - [spec] C++ and Objective-C are not single tokens
On Thursday, 25 November 2021 at 11:25:49 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
I am not asking this questions out of thin air, I am trying to
write a conforming lexer and this is one of the ambiguities.
I think it is easier to just look
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
#
//this works
line
I hate `#`.
On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
Well:
```
#line IntegerLiteral Filespec? EndOfLine
```
Having EndOfLine at the end means for me that there are no
other EOLs between, otherwise this syntax should pass but it's
not (DMD last):
```d
#line 12
"source.d"
```
The
On Thursday, 25 November 2021 at 10:41:05 UTC, Rumbu wrote:
I am not asking this questions out of thin air, I am trying to
write a conforming lexer and this is one of the ambiguities.
I think it is easier to just look at the lexer in the dmd source.
The D language does not really have a
On Thursday, 25 November 2021 at 10:10:25 UTC, Dennis wrote:
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Also, this works also for #line, even if the specification
tells us that all tokens must be on the same line
Where does it say that?
Well:
```
#line IntegerLiteral
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Also, this works also for #line, even if the specification
tells us that all tokens must be on the same line
Where does it say that?
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Is that ok or it's a lexer bug?
@ (12) does exactly what I would expect. @nogc I always assumed
was a single token, but the spec says otherwise. I suppose that
makes sense.
#line is dicier as it is not part of the grammar
On Thursday, 25 November 2021 at 08:06:27 UTC, rumbu wrote:
Is that ok or it's a lexer bug?
Yes. The lexer just eats whitespace and the parser accepts way
too much.
Just playing around with attributes.
This is valid D code:
```d
@
nogc: //yes, this is @nogc in fact, even some lines are between
@
/* i can put some comments
*/
/** even some documentation
*/
// single line comments also
(12)
// yes, comments and newlines are allowed between
On Friday, 5 November 2021 at 06:19:16 UTC, Li30U wrote:
...e.g.
```d
// ...
mixin ("ReturnType /*...snip...*/ " ~ member ~ "()(Parameters!
/*...snip...*/
```
Note the `()` before parameter list. This would make your member
function a function template, for which attributes wi
On Friday, 5 November 2021 at 06:19:16 UTC, Li30U wrote:
I am creating a templated object that is a storehouse for a
heap object and executes their methods and returns an array of
results. With the help of a template, I want to achieve this,
but I want to assign the same attributes
I am creating a templated object that is a storehouse for a heap
object and executes their methods and returns an array of
results. With the help of a template, I want to achieve this, but
I want to assign the same attributes to the function. How can one
pass the attributes of a function
On Sunday, 18 July 2021 at 11:03:24 UTC, Adam D Ruppe wrote:
Fun fact there: any child implementations do NOT need to
specify the attribute there; the compiler will copy it from the
interface for you.
I suppose these are the day-to-day minor details you can rely on
to avoid typing a lot of
On Sunday, 18 July 2021 at 03:27:04 UTC, someone wrote:
I have an interface with function members *not* being declared
@safe (at first glance it seemed irrelevant to me just to mark
@safe a declaration and not an actual implementation).
Yeah, that'd be promising all child implementations are
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote:
From the interface perspective: are these signatures identical
or not ?
No, they are very different.
This helped me solve an issue that I carried since a few days ago:
I have an interface with function members *not* being
On Saturday, 17 July 2021 at 22:48:00 UTC, Adam D Ruppe wrote:
On Saturday, 17 July 2021 at 22:43:15 UTC, someone wrote:
So the lesson learned is that interfaces can also mandate
member function's parameter attributes then ... right ?
A subclass must accept anything the parent class can
On Saturday, 17 July 2021 at 22:43:15 UTC, someone wrote:
So the lesson learned is that interfaces can also mandate
member function's parameter attributes then ... right ?
A subclass must accept anything the parent class can, but it can
also make it stricter if you want.
class Base
On Saturday, 17 July 2021 at 21:01:00 UTC, Adam Ruppe wrote:
No, they are very different.
So the lesson learned is that interfaces can also mandate member
function's parameter attributes then ... right ?
But you also don't gain much from const here and that ref is
probably actively
On Saturday, 17 July 2021 at 20:42:06 UTC, someone wrote:
From the interface perspective: are these signatures identical
or not ?
No, they are very different.
But you also don't gain much from const here and that ref is
probably actively harmful so i wouldn't use them here.
```d
public interface intefaceWhatever {
public bool doSomething(
dstring lstrID,
classX robjX
);
}
```
vs
```d
public interface intefaceWhatever {
public bool doSomething(
const dstring lstrID,
ref classX robjX
);
}
```
From the interface
the
allocator.
If they are templates, just don't specify attributes and the
compiler will infer them for you.
If they are not templates, you have to do a separate copy under
version or static if.
That's good to know. Thanks :)
A separate copy is exactly what I wanted to avoid but since
attributes and the
compiler will infer them for you.
If they are not templates, you have to do a separate copy under
version or static if.
Hi,
Consider Allocators, e.g.:
```d
struct Mallocator
{
enum usesGC = false;
/// implement alloc, free, etc. @nogc
}
struct GCAllocator
{
enum usesGC = true;
/// implement alloc, free, etc. via the GC
}
```
Now I want to have the function attributes set depending
On Tuesday, 14 July 2020 at 00:17:14 UTC, solidstate1991 wrote:
Something like that, but with @safe, pure, etc. attributes.
I've tried to "bruteforce" it by generating functions with
combinations of attributes, and it kinda works, but is a very
janky solution.
I'll brainstor
On Tuesday, 7 July 2020 at 20:53:05 UTC, Ali Çehreli wrote:
I am not sure whether I understand it correctly but there has
been a request for opApply() to gain the attributes of the
delegate (or the range?). In other words, "transfer the
attributes to opApply". This is needed beca
there has been a
request for opApply() to gain the attributes of the delegate (or the
range?). In other words, "transfer the attributes to opApply". This is
needed because I want opApply() to work with any foreach body,
attributes of which opApply() cannot know.
I am sure I created an issu
)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Unfortunately this doesn't really work, even with explicitly
defined foreach arguments.
)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Yeah, but unfortunately then this won't work:
foreach(elem; test) {
assert(elem == key);
}
you'd have to spell out the types for `elem`.
int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts to
`scope int delegate(ref E)`, this version will accept both @safe
and non-@safe delegates. (And likewise for the other function
attributes.)
slower) to implement that within a
binary search tree.
Should I change the `opApply` into the `popfront` - `front` -
`empty` trinity, or write a template that overrides all the
potential attribute combinations?
Maybe D needs a template for attributes somehow, or something
like that.
On 2020-05-12 06:02, Steven Schveighoffer wrote:
If you want a list of ALL symbols that have the UDA in the application,
that would require some form of runtime reflection (like Java). D has
very limited support for runtime reflection. In D, you would use some
form of registration to tell the
On Tuesday, 12 May 2020 at 04:02:18 UTC, Steven Schveighoffer
wrote:
In the case of serialization/deserialization, you give an
instance of a type to serialize or deserialize. Then the
library can search the symbols inside that type to see if any
has the UDA you are looking for.
In the Rust
On 5/11/20 11:30 PM, Doug wrote:
On Tuesday, 12 May 2020 at 02:53:53 UTC, Adam D. Ruppe wrote:
see std.traits.getSymbolsByUDA
Thanks for the link. I did see that one. But that function searches
within known symbols. My use case if for a library that's used outside
of my application. In
On Tuesday, 12 May 2020 at 02:53:53 UTC, Adam D. Ruppe wrote:
see std.traits.getSymbolsByUDA
Thanks for the link. I did see that one. But that function
searches within known symbols. My use case if for a library
that's used outside of my application. In that case, I wouldn't
know which
On Tuesday, 12 May 2020 at 02:51:39 UTC, Doug wrote:
So far I've only seen a way to get unknown UDAs from known
symbols but not how to get unknown symbols from UDAs. Is there
any documentation for how to get a list of symbols annotated
with a specific UDA?
see std.traits.getSymbolsByUDA
I've seen a lot of examples of how to get a list of User Defined
Attributes from a known symbol but I haven't seen any for how to
get a list of symbols when only the UDA is known.
The use case is the same as seen in Rust with Serde[1]. Library
users annotate a struct to mark
On Saturday, 18 April 2020 at 09:19:48 UTC, Simen Kjærås wrote:
On Wednesday, Friday, 17 Apr 2020 17:45:47 UTC, H. S. Teoh
wrote:
I wonder if the ultimate cause of the above case is ultimately
caused by
the change to import semantics that hid private symbols from
outside the
module. Perhaps
On Wednesday, Friday, 17 Apr 2020 17:45:47 UTC, H. S. Teoh wrote:
I wonder if the ultimate cause of the above case is ultimately
caused by
the change to import semantics that hid private symbols from
outside the
module. Perhaps something, somewhere, is triggering an illegal
access of
a
On Friday, 17 April 2020 at 18:05:39 UTC, Jean-Louis Leroy wrote:
Interesting example, but all hope is not lost. `a` could
(should?) be passed as an alias in __parameters.
Well, __parameters itself actually kinda works. The compiler
knows it is an expression and can stringify it or evaluate
On Friday, 17 April 2020 at 18:05:39 UTC, Jean-Louis Leroy wrote:
Interesting example, but all hope is not lost. `a` could
(should?) be passed as an alias in __parameters.
Okay I take this back...
On Friday, 17 April 2020 at 17:48:06 UTC, Adam D. Ruppe wrote:
On Friday, 17 April 2020 at 17:31:32 UTC, Jean-Louis Leroy
wrote:
Well, can't do. I need this purely at compile time, and
cross-module.
And the CTFE engine gets weird with it too dmd will have to
fix this.
But default
On Friday, 17 April 2020 at 17:31:32 UTC, Jean-Louis Leroy wrote:
Well, can't do. I need this purely at compile time, and
cross-module.
And the CTFE engine gets weird with it too dmd will have to
fix this.
But default parameters might not be possible in general at CT
anyway... it is
On Fri, Apr 17, 2020 at 05:33:23PM +, Simen Kjærås via Digitalmars-d-learn
wrote:
> On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
[...]
> > So pragma(msg) is doing something really weird, the bug doesn't
> > appear to be in Phobos per se, I think it is the compiler doing the
On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
and it is fine.
Well, can't do. I need this purely at compile time, and
cross-module. That's for supporting UDAs and default parameter
On Friday, 17 April 2020 at 16:54:42 UTC, Adam D. Ruppe wrote:
This part seems fine...
pragma(msg, ParameterDefaults!f.stringof);
It is this, specifically, that causes the problem. Replace it
with:
void main() {
import std.stdio;
writeln(ParameterDefaults!f.stringof);
}
On Friday, 17 April 2020 at 16:40:15 UTC, Jean-Louis Leroy wrote:
Alas the presence of parameter UDAs breaks
std.traits.ParameterDefaults:
import std.traits;
struct attr;
void f(@attr int);
This part seems fine...
pragma(msg, ParameterDefaults!f.stringof);
It is this, specifically,
Alas the presence of parameter UDAs breaks
std.traits.ParameterDefaults:
import std.traits;
struct attr;
void f(@attr int);
pragma(msg, ParameterDefaults!f.stringof);
Error:
dmd -c bug.d
bug.d(4): Error: undefined identifier `attr`, did you mean
variable `ptr`?
Thanks to both of you!
As part of implementing full support for attributes in
openmethods, I am developing a reflection library. That helped a
lot.
is() is a bit weird, but I described it in my "D Cookbook" to
some success...
I am going to order it...even though it is not
On Wed, Apr 15, 2020 at 12:01:51AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
[...]
> is() is a bit weird, but I described it in my "D Cookbook" to some
> success... and writing that description helped me make sense of it.
> The docs list like seven forms of it, but they are mostly just
On Tuesday, 14 April 2020 at 21:54:14 UTC, Jean-Louis Leroy wrote:
O.kay. It looks like `is` is D's Swiss army chainsaw.
Aye, is and __traits are the two built-in compile-time reflection
avenues. The phobos std.traits things (for the most part, look at
the source for the default
On Tuesday, 14 April 2020 at 21:44:51 UTC, Adam D. Ruppe wrote:
On Tuesday, 14 April 2020 at 21:35:12 UTC, Jean-Louis Leroy
wrote:
I can see them:
There's some weird tricks to it. Check out my old blog sidebar
about it here:
On Tuesday, 14 April 2020 at 21:35:12 UTC, Jean-Louis Leroy wrote:
I can see them:
There's some weird tricks to it. Check out my old blog sidebar
about it here:
http://dpldocs.info/this-week-in-d/Blog.Posted_2019_02_11.html#how-to-get-uda-on-a-function-param
I can see them:
import std.traits;
struct foo;
struct bar;
void f(@foo int, @foo @bar @("baz") real);
pragma(msg, Parameters!f);
// (@(foo) int, @(tuple(tuple(foo), tuple(bar)),
tuple("baz")) real)
...but I cannot find how to get hold of them:
pragma(msg,
On Sunday, 12 April 2020 at 23:14:42 UTC, Bruce Carneal wrote:
Could dlang compilers emit aliases for extern(C) and
extern(C++) routines that would carry dlang specific
information? (@safe, @nogc, nothrow, ...)
I'm thinking two symbols. The first as per normal C/C++, and
the second as per
Could dlang compilers emit aliases for extern(C) and extern(C++)
routines that would carry dlang specific information? (@safe,
@nogc, nothrow, ...)
I'm thinking two symbols. The first as per normal C/C++, and the
second as per normal dlang with a "use API {C, C++, ...}" suffix.
On Thursday, 20 February 2020 at 17:41:54 UTC, Dennis wrote:
On Tuesday, 18 February 2020 at 17:11:55 UTC, Marcel wrote:
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this?
The best I can think of
strings.
It has been proposed quite a few times to have a way to
enable/disable attributes based on a compile-time boolean. But
it's never come close to getting included.
-Steve
That's a shame...
/disable
attributes based on a compile-time boolean. But it's never come close to
getting included.
-Steve
On Tuesday, 18 February 2020 at 17:11:55 UTC, Marcel wrote:
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this?
The best I can think of is:
```
mixin template maybeStatic() {
void foo() {
Hello!
Say I have a struct where every member function can either be
static or not depending on a template parameter. Is there a
simple way to do this? Like, for example:
struct Foo(Condition)
{
static if (Condition) static:
void Bar() {}
void Baz() {}
}
On Thursday, June 13, 2019 3:49:04 AM MDT Jacob Carlborg via Digitalmars-d-
learn wrote:
> On 2019-06-12 22:42, Mek101 wrote:
> > I didn't know it applied to templates other than lambdas.
> >
> > Thank you for your explanation.
>
> It applies to templates, lambdas (which basically are templates)
On 2019-06-12 22:42, Mek101 wrote:
I didn't know it applied to templates other than lambdas.
Thank you for your explanation.
It applies to templates, lambdas (which basically are templates) and
nested functions.
--
/Jacob Carlborg
I didn't know it applied to templates other than lambdas.
Thank you for your explanation.
> > if(predicate(array[i]))
> > return i;
> > return size_t.max;
> > }
>
> Say that I may want to use the function in a @nogc scope, providing a
> @nogc callable, but I also want to reuse the same code in managed
> scope while p
return i;
return size_t.max;
}
Say that I may want to use the function in a @nogc scope,
providing a @nogc callable, but I also want to reuse the same
code in managed scope while passing a delegate: how can I apply
the attributes of the given callable to the function so that
they're
On Sunday, 14 April 2019 at 02:11:52 UTC, Mike Franklin wrote:
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
...
It's a long standing issue (going on 7 years old)
...
I plan on getting to it, but there are other pressing
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls foo.bar();
foo.bar = 10; // calls foo.bar(10
On 2019-04-02 15:23, Alex wrote:
__traits(getAttributes, T)
Requires a type and a field is unfortunately not a type ;/
enum attr;
struct Foo
{
@attr int a;
}
void main()
{
alias a = __traits(getAttributes, Foo.a);
}
--
/Jacob Carlborg
On Tuesday, 2 April 2019 at 13:36:47 UTC, Alex wrote:
On Tuesday, 2 April 2019 at 13:23:37 UTC, Alex wrote:
__traits(getAttributes, T)
Requires a type and a field is unfortunately not a type ;/
I'd like to be able to get the attributes without having to
instantiate the base type because
On Tuesday, 2 April 2019 at 13:23:37 UTC, Alex wrote:
__traits(getAttributes, T)
Requires a type and a field is unfortunately not a type ;/
I'd like to be able to get the attributes without having to
instantiate the base type because that is problematic and I see
no reason why it has
__traits(getAttributes, T)
Requires a type and a field is unfortunately not a type ;/
the @safe version of
that type, i.e. int delegate(int) @safe?
I tried
alias SafeOf(DG) = DG @safe;
but it didn't compile.
The case is not @safe-specific; it's the same for all function
attributes.
At https://p0nce.github.io/d-idioms/
there is a demonstration for @nogc:
´´´
import std.traits
tried
alias SafeOf(DG) = DG @safe;
but it didn't compile.
The case is not @safe-specific; it's the same for all function
attributes.
At https://p0nce.github.io/d-idioms/
there is a demonstration for @nogc:
´´´
import std.traits;
// Casts @nogc out of a function or delegate type.
auto
.
The case is not @safe-specific; it's the same for all function
attributes.
On Fri, 30 Nov 2018 22:10:11 +, ikod wrote:
> Thanks for explanation, got it.
>
> My case is actually
>
> interface I(K,V)
> {
> int get()(K);
> }
Interface functions must be abstract. Templated functions are implicitly
final. Final things can't be abstract.
If there's something
1 - 100 of 355 matches
Mail list logo
