Re: foreach() behavior on ranges

2021-08-25 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven 
Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost 
always the equivalent `save` implementation.


-Steve


Really?

Then what is the use for .save method then?
The only reason I can find is that you can't declare constructors 
in interfaces hence the use of the .save method instead of copy 
constructor for defining forward ranges.


We have now two ways of doing the same thing, which can cause 
confusion. Best would be then for ranges to hide copy constructor 
under private modifier (or disable altoghether), and force other 
range wrappers call .save always, including foreach since by not 
doing so we introduce difference in behavior between ref and 
value forward ranges (for foreach use).





Re: foreach() behavior on ranges

2021-08-25 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:

I know, but foreach() doesn't call save().


Hmm, this is a regression probably, or I missed the time frame 
when foreach moved to use of copy constructor for forward ranges.


Do we have a well defined description of what input, forward and 
any other well known range is, and how it does interact with 
language features?


For some reason I didn't manage to find anything on dlang.org.


Re: foreach() behavior on ranges

2021-08-25 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 25 August 2021 at 06:51:36 UTC, bauss wrote:
Of course it doesn't disallow classes but it's generally 
advised that you use structs and that's what you want in 99% of 
the cases. It's usually a red flag when a range starts being a 
reference type.


Well, sometimes you can't avoid ref types. For example when you 
need to mask the implementation of the range, but yes, in most of 
the cases best is to use simpler methods to represent ranges.


Re: foreach() behavior on ranges

2021-08-24 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:


A range should be a struct always and thus its state is copied 
when the foreach loop is created.


Actually the range contracts don't mention that it needs to be a 
by value type. It can also be a reference type, i.e. a class.




Which means the state resets every time the loop is initiated.


True for any forward range and above, not true for input ranges. 
The problem with them is that some of them are structs, and even 
if they are not forward ranges they do have this behavior due to 
implicit copy on assignment, which can potentially make the code 
confusing.


If your range uses some internal state that isn't able to be 
copied then or your ranges are not structs then your ranges are 
inherently incorrect.


If we follow the definition of ranges, they must not be copy-able 
at all. The only way to copy/save, would be to have .save method 
and call that method. This again is not being properly followed 
by even phobos implementations.


Note, that a better approach would be to replace .save in 
definition of forward range with a copy constructor, then all 
non-compliant ranges would become suddenly compliant, while those 
that have .save method should be refactored to a copy constructor 
version.




This is what a foreach loop on a range actually compiles to:

```d
for (auto copy = range; !copy.empty; copy.popFront())
{
...
}
```


You should add .save on assignment if range is a forward range, 
or just remove the assignment if it is not.


Best regards,
Alexandru.




Re: foreach() behavior on ranges

2021-08-24 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
How do you handle that issue? Are your ranges designed to have 
this bug or do you implement opApply() always?


This is expected behavior imho. I think what you need is a 
forward range, not input range. By the contract of input range, 
it is a consumable object, hence once used in a foreach it can't 
be used anymore. It is similar to an iterator or a stream object 
in java.


Forward range exposes also capability to create save points, 
which is actually used by foreach to do, what it is done in java 
by iterable interface for example.


Then there is bidirectional and random access ranges that offer 
even more capabilities.


Per knowledge I have opApply is from pre range era, and is kinda 
left as an option to provide easy foreach integration. In this 
case you can think of objects having opApply as forward ranges, 
though just for foreach constructs only.


Regards,
Alexandru.


Re: Lexicographical object comparison by selected members of a struct

2021-08-20 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Saturday, 21 August 2021 at 04:34:46 UTC, Ali Çehreli wrote:

...


Consider __traits(identifier, member) instead. This one should 
return member name as string, removing the need of memberName 
function.


Also you could have an annotation @Equality.Include for example, 
and make mixin scan fields for it and include only those fields 
and methods that have it into compariosn and hashing.


Another problem that may arise is storage in local variable of 
fields before comparison, it might introduce unnecessary copy.


Regards,
Alexandru.


Re: Lexicographical object comparison by selected members of a struct

2021-08-20 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Saturday, 21 August 2021 at 05:34:59 UTC, Alexandru Ermicioi 
wrote:

...


Also there is no need for mixing string code here. You can get 
the field using __traits(getMember, this, member).


Re: simple (I think) eponymous template question ... what is proper idimatic way ?

2021-08-17 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Tuesday, 17 August 2021 at 19:53:52 UTC, james.p.leblanc wrote:


Wow!  That is absolutely beautiful ... I had never seen (or even
imagined) a recursive template!  This expands my mind in a good
way ... and is going into my toolbox immediately.

Best Regards,
James


Just don't over rely on it. It can cause compilation slowdowns, 
so avoid it if you can.


Re: simple (I think) eponymous template question ... what is proper idimatic way ?

2021-08-17 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Tuesday, 17 August 2021 at 18:11:56 UTC, james.p.leblanc wrote:

Is there a more elegant way, to do this?

Regards,
James

PS Any violations should be caught at compile time.


That is template specialization:

```
auto moo(T : YourSpecialClassOrDType)(T myMoo) {•••}
```

You can also declare other overloads of the method, just make 
sure they don't overlap in the constraints, otherwise you'd get 
ambiguous call exception.


Regards,
Alexandru.


Re: Getting a working example of opIndexAssign using opSlice ... have troubles ...

2021-08-16 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Monday, 16 August 2021 at 06:36:02 UTC, james.p.leblanc wrote:

To be honest, I am not exactly sure what is happening here. I
am unfamiliar with the "(T : T[])" syntax ... need to read


That is template argument secialization. You're saying that T can 
be accept only types that are arrays of T, where : reads as 
'extends'.


Now T : T[] might introduce cyclic reference, so more correct 
would be: foo(T : Z[], Z)(...)


Here you say that T might accept only types that are arrays of Z 
elements.


Regards,
Alexandru.


Re: Drawbacks of exceptions being globally allocated

2021-08-16 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Monday, 16 August 2021 at 06:12:14 UTC, Tejas wrote:

...


Fyi, check out std.exeprimental.allocator package. You can use 
allocators from there to do allocation of exceptions, on the heap 
or any other region.


Re: Drawbacks of exceptions being globally allocated

2021-08-15 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Sunday, 15 August 2021 at 16:23:25 UTC, Ali Çehreli wrote:

That output contains two automatically chained exceptions:

Failed: Main failed
This failed too: The destructor failed

Ali


Hmm, wasn't aware of such use case (results of too much java :)). 
Considering this case I'd say it is better to keep it, because 
having more info than less is better for debugging. Even in your 
example, you already catch an use case that wasn't accounted for, 
that may or may not require fixing, i.e. it is better to know it 
then be in blissfull unawareness.


Though it is annoying to view those chained stacks, since they 
have repetitions. It would be nice if stack traces of nested 
exceptions would just show lines up to next exception thrown 
similar to how java does.


Regards,
Alexandru


Re: Drawbacks of exceptions being globally allocated

2021-08-15 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Sunday, 15 August 2021 at 00:15:32 UTC, Ali Çehreli wrote:

Even though this feature is probably never used, in D, multiple 
exception objects are chained. For example, you can throw e.g. 
in a destructor when there is an active exception in flight and 
that second object gets attached to the first one in linked 
list fashion.


This may be useful in some cases but in general, these 
colatteral exceptions don't carry much information and I don't 
think anybody looks at them. Usually, the first one is the one 
that explains the error case.
That is just an assumption. There could be designs where original 
exception gets wrapped in another one to comply with some 
interface, and in such cases, having entire chain visible, is 
useful. Also exceptions carry the stack trace which is useful, in 
debugging, allowing you to know possible location of the bug.


Regarding exception chaining, do you mean that it will 
automatically get chained, even without explicitly passing it as 
constructor of wrapping exception?


If so, it indeed might be best to remove such functionality, and 
just force user to do this by himself. He will then be able to 
decide whether chained exception does or does not carry any 
useful meaning.


Regards,
Alexandru




Re: Drawbacks of exceptions being globally allocated

2021-08-14 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Saturday, 14 August 2021 at 13:24:22 UTC, Tejas wrote:

...


I don't think there are any gotchas here. The problem with this 
technique, is when your exceptions aren't just simple labels but 
also carry some additional data, say for example specific error 
type, and subject that, caused this. In such cases you can't have 
a gloablly shared instance. Let's say it's doable but has lot's 
of drawbacks.


Regards,
Alexandru.


Re: __traits() to get parameter details only ? ... hasMember looks up everything within

2021-08-04 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 4 August 2021 at 22:28:53 UTC, someone wrote:

Is that what you mean ?


Not really. I was assuming you were talking about @property 
methods, and if so you could declare such cases:


```
interface HasMutableLstrSymbolId {
 @property lstrSymbolId();
 @property lstrSymbolId(string id);
}

interface HasMutableLstrCurrencyId {
 @property lstrCurrencyId();
 @property lstrCurrencyId(string id);
}

class NyseTicker : HasMutableLstrSymbolId {
 //...
}

class NasdaqTicker : HasMutableLstrSymbolId, 
HasMutableLstrSymbolId  {

 // ...
}
```

Having this structure you would just need to check whether it 
implements right interface and then once you know it, just set 
the value. Note, that this approach won't work nicely if you have 
lots of fields to set. In this case I'd try a builder pattern, 
where you have a common builder interface which has Nasdaq and 
Nyse implementation that builds respective classes out of 
information available.


Now from the other replies it seems you want to get constructor 
arguments. Constructor itself is named __ctor internally (you'll 
see it listed as such when fetching allMembers), therefore fetch 
the constructor overload set (you need this because D allows 
method overloading, and therefore all methods in overload set 
should be checked), and then iterate over it and check what 
you're interested in. You can then use std.traits.Parameters to 
fetch a tuple of param types, or 
std.traits.ParameterIdentifierTuple for fetching parameter names. 
As other people recommended you can check std.traits 
implementation to get insight on the compiler magic they rely to 
do this.


Regarding @property methods, even if they are half baked, they 
are still useful in denoting properties that can be fetched or 
assigned to a class. It is similar to setters & getters 
convention in Java, or [set,get] functionality from C# as far as 
I'm aware. Having properties marked with @property also allows 
template code to be aware which methods are actually representing 
a property on the object.


Also, it is not really necessary to prefix the name of each class 
or interface with 'class' or 'interface', since this information 
is already baked into the type itself, and in most of the time 
may be just unnecessary noise for reading the code.


Re: __traits() to get parameter details only ? ... hasMember looks up everything within

2021-08-04 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 4 August 2021 at 15:08:24 UTC, someone wrote:

However, __traits(hasMember, ...) checks for the existence of 
anything labeled lstrCurrencyID within the class (eg: unrelated 
variables with same name; not gonna happen, but, I like to code 
it the right way); so, question is: is there any way to search 
the parameter declarations only ?


Something akin to 
https://dlang.org/spec/traits.html#getParameterStorageClasses 
but for the parameter types/labels


What do you mean by parameter type?
Are you referring to @property functions or just whether there is 
a field in there?


In both cases you need to get that symbol with __traits(getMember 
...).
If it is about @property then check whether the symbol is a 
function and if so fetch the function attributes with  
functionAttributes template and check if it is marked as a 
property.


If this is about field of the class then you can test with 
FieldNameTuple.


Since you're using classes consider just declaring an interface 
that denotes that implementor has this field, it would be much 
easier to check for it, and easier for compiler since it avoids 
compile time magic.


Best regards,
Alexandru.


Re: how much "real-life" code can be marked @safe ?

2021-07-04 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Saturday, 3 July 2021 at 20:09:56 UTC, tsbockman wrote:
On Saturday, 3 July 2021 at 16:06:33 UTC, Alexandru Ermicioi 
wrote:
3. An edge case. Ex: You need to mutate some data and then 
assume it is immutable in a constructor.


Can you give a valid example where that is necessary? The main 
examples that I can think of either can be `@safe` with the 
right API, or are motivated by a desire to avoid the GC and/or 
druntime, thus falling under (1).


Can't remember any specific code now, but suppose you have a 
mutable object as input to a function or constructor. You need to 
return or assign an immutable copy of that struct and you can do 
that with right copy constructor on that object, but before that 
you need to do a couple of mutations on that object. In this use 
case you can't avoid cast(immutable) easily. Note: it is desired 
to not mutate the original object.


The summary is this: the construction of immutable instances can 
be done just through initialization statement. You can't mutate 
the instance and then assign/assume it as an immutable.


4. Functionality that doesn't account for @safe/immutable or 
any other features when it can in standard library.


True, although it's just another example of my point (2). The 
standard library and druntime are dependencies, too...


Right, didn't take it that way.



The one exception here is when the array is already typed 
`inout` before it is passed to the constructor. But, that's an 
example of (2) since this logic applies transitively throughout 
the call stack: if you need to call `dup` anywhere, don't erase 
the constness with `inout`.


Yeah this is a working workaround, for this specific use case. I 
still would prefer inout version, even if I need to do some 
unsafe casts due to clear intentions it gives the user, and 
better errors.

Anyway this is just a proof of your 2nd point.




Re: how much "real-life" code can be marked @safe ?

2021-07-03 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 2 July 2021 at 22:08:31 UTC, tsbockman wrote:

(Responding out of order:)

On Friday, 2 July 2021 at 00:26:52 UTC, someone wrote:
But when you start attempting to declare @safe chunks of code 
that actually DO things ... well, it seems end-of-the-story.


If you find yourself unable to get real work done in `@safe` 
code, this is almost certainly a sign of one of the following 
problems:


0) You don't fully understand the purpose and valid use of any 
or all of the `@trusted`, `inout`, `scope`, and `return` 
annotations.


1) Your code is avoiding use of the garbage collector, and/or 
does not have `-dip1000` enabled. (`@safe` is still quite 
useful without the garbage collector, but even with `-dip1000` 
you'll still need a lot of `@trusted` code.)


2) You have at least one dependency that isn't correctly 
designed for use with `@safe`.


I'd add:
3. An edge case. Ex: You need to mutate some data and then assume 
it is immutable in a constructor.


4. Functionality that doesn't account for @safe/immutable or any 
other features when it can in standard library. Take for example 
array.dup, there is no inout alternative for it, and you're 
pretty much stuck with trusted code, when you'd like to dup an 
array that is inout.

manual.

Although these two should be on the lowest place in this list by 
priority.





Re: how much "real-life" code can be marked @safe ?

2021-07-02 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 2 July 2021 at 00:26:52 UTC, someone wrote:

... just wondering:
...


Imho, if you want all of the app to be safe, and you cannot avoid 
unsafe code, then there are two choices:
1. Mark the method doing unsafe stuff as @trusted, or pieces of 
code which are unsafe with trusted lambda hack.

2. Mark the top caller of your @system methods as @trusted.

In both cases, unsafe code should be manually checked as best as 
it can be done. Best is to think twice whether you can redesign 
your code to avoid unsafe operations.


On PR review step if there is such thing for your app, reviewers 
should carefully review those @trusted blocks of code.


Oh well, and tests, tests and more tests, i.e. It should be 
thoroughly tested.


Best regards,
Alexandru.


Re: Printing Tuple!(...)[] using for loop?

2021-07-02 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 2 July 2021 at 04:21:24 UTC, Kirill wrote:

...


1. use static foreach for tuple loop.
2. start column and end column should be known at compile time. 
Either make them immutable, or as enum constant, or pass them as 
an template argument.


Tuple is basically a wrapper over built in tuple support from D. 
Check it's insides to se how it is done. So to index a field in a 
tuple you need to know which field you want to access at compile 
time since, each field in a tuple has different size, and cannot 
be indexed at runtime easily.


Best regards,
Alexandru.


Re: Error: function `...` without `this` cannot be `const`

2021-06-30 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 30 June 2021 at 20:12:29 UTC, H. S. Teoh wrote:
On Wed, Jun 30, 2021 at 07:40:40PM +, someone via 
Digitalmars-d-learn wrote: [...]

@property int data() { return m_data; } // read property

[...]

string something() @property { return this.whatever; }

[...]

Now I am not sure which is the correct way.

[...]

Both are correct. :-)  It's up to personal style preference.


T


Just to remark here, if you want to apply const to a return type 
put it inside brackets like: const(MyClass) foo(); otherwise 
compiler will try to apply it to 'this' parameter.


Best regards,
Alexandru.


Re: Error: function `...` without `this` cannot be `const`

2021-06-30 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 30 June 2021 at 17:47:05 UTC, someone wrote:

...


That is because const/immutable/shared are being applied on the 
object hence 'this' variable inside function body if function is 
a member of a struct or class. It doesn't make sense to have a 
const modifier on a simple function. What will that const mean 
then in context of that function? To what it will be applied?


Best regards,
alexandri.


Re: cloning array

2021-06-03 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Wednesday, 2 June 2021 at 15:32:38 UTC, Sean wrote:

...


You can implement deep copy using template recursion:

import std;

T[] rdup(T : U[], U)(T[] duped) {
return duped.map!(arr => arr.rdup).array;
}

T[] rdup(T)(T[] duped) {
return duped.dup;
}

void main()
{
int[][][] dupeable = [[[1], [2]], [[3]]];
auto duped = dupeable.rdup;
duped[0][0][0] = 9;
writeln("Hello D-eep copy of ", dupeable, " to ", duped);
}

Best regards,
Alexandru.


Re: Wrong selection of opEquals for objects.

2020-08-28 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 28 August 2020 at 12:29:20 UTC, Simen Kjærås wrote:




Seems that these methods should be rooted out from Object, and 
placed in respective interfaces like:


-
interface Equatable(T) {
bool opEquals(T value);
}
-

Then it would be a lot more simple. People who want equality 
check, will implement interface with right type, for example 
Equatable!Object.


- Alex


Re: Wrong selection of opEquals for objects.

2020-08-28 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Friday, 28 August 2020 at 10:42:09 UTC, Alexandru Ermicioi 
wrote:

...
Also, why it is limited to just objects? It seems that this 
function enforces symmetry between two objects. What about rest 
of the possible types, such as structs, unions?


Re: Wrong selection of opEquals for objects.

2020-08-28 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 28 August 2020 at 10:28:07 UTC, Simen Kjærås wrote:

What you'll need to do is mark every function that does compare 
two class objects with == as @trusted or @system.


No that is not a solution at all, in template code that requires 
safety. You basically will have to sacrifice safety for rest of 
types, such as structs, unions & enums for the sake of objects 
being able to compare.


Could we just template that opEquals in this manner:
---
bool opEquals(T : Object, X : Object)(T lhs, X rhs)
{
if (lhs is rhs) return true;

if (lhs is null || rhs is null) return false;

if (!lhs.opEquals(rhs)) return false;

if (typeid(lhs) is typeid(rhs) ||
!__ctfe && typeid(lhs).opEquals(typeid(rhs)))
{
return true;
}

return rhs.opEquals(lhs);
}
---

That would at least allow us to define an overload which is safe 
and would be picked up by new implementation.


I'm wondering why it wasn't done yet, are there any reasons for 
that?


- Alex.



Re: Wrong selection of opEquals for objects.

2020-08-28 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Friday, 28 August 2020 at 08:16:01 UTC, Alexandru Ermicioi 
wrote:

Hi everyone,



Would be glad at least to pointers, where in dmd is logic for 
operator overloading happens, as well as for overloading rules, 
so I could fix it myself, if no-one is able to pick up it.


Wrong selection of opEquals for objects.

2020-08-28 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi everyone,

there is https://issues.dlang.org/show_bug.cgi?id=21180 bug, 
anyone knows how to avoid it?


Test case:
-
import std;

class Silly {
bool opEquals(const Silly silly) const @safe {
return silly is this;
}

alias opEquals = Object.opEquals;
}

bool comp(T)() @safe {
return new T() == new T();
}

void main()
{
comp!Silly.writeln;
comp!(const Silly).writeln;
comp!(immutable Silly).writeln;
}
-

It always tries to call Object.opEquals, when narrower overload 
should've been selected.


- Alex.


Re: Call method if declared only

2020-03-01 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 28 February 2020 at 06:12:37 UTC, Виталий Фадеев wrote:

How to implement ?


I would go for a template mixin that implements send operation in 
each subclass. Sine template mixin's content is declared in scope 
of declaration not template's module, the code inside it is aware 
of concrete implementation of your base class, and could 
introspect all methods available in it, and generate your switch 
statement (in send operation) for all supported messages.


This would be just one line of code in each class with no 
complication whatsoever.


Best regards,
Alexandru.


Re: How create a function that receive a function and run it in another threading?

2019-12-30 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 27 December 2019 at 07:06:52 UTC, mipri wrote:

On Friday, 27 December 2019 at 06:08:16 UTC, Marcone wrote:

import std;
import core.thread;

auto threading(lazy void fun){ return 
task!fun().executeInNewThread(); }


void main(){
threading(writeln("Hello World!"));
}


I want to create a function threading() to run some function 
in other threading, but I get this error bellow. How can I get 
success?



Error: static function Programa.threading.Task!(fun).Task.impl 
cannot access frame of function Programa.threading
Error: template instance `Programa.threading.Task!(fun)` error 
instantiating


This works:

import std;
import core.thread;

auto threading(void function() fun){ return 
task(fun).executeInNewThread(); }


void main(){
writeln("Main: ", thisTid);
threading({ writeln("Hello, ", thisTid); });
}


or you can use just 
https://dlang.org/library/std/concurrency/spawn.html from 
std.concurrency to avoid needless bike construction.


Best regards,
Alexandru.


Re: What type does byGrapheme() return?

2019-12-30 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Friday, 27 December 2019 at 17:26:58 UTC, Robert M. Münch 
wrote:

...


There are set of range interfaces that can be used to mask range 
type. Check for 
https://dlang.org/library/std/range/interfaces/input_range.html 
for starting point, and for 
https://dlang.org/library/std/range/interfaces/input_range_object.html for wrapping any range to those interfaces.


Note: resulting wrapped range is an object and has reference 
semantics, beware of using it directly with other range 
algorithms as they can consume your range.


Best regards,
Alexandru.


Re: equivalent of typeid(Class).name at compile-time

2019-11-22 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Thursday, 21 November 2019 at 20:48:03 UTC, Adam D. Ruppe 
wrote:
On Thursday, 21 November 2019 at 20:45:16 UTC, Steven 
Schveighoffer wrote:
To clarify, I need the compile time string that will match 
typeid(instance).name, so I can match the derived type.


You have to make sure that the derived type is passed to your 
register function, but then std.traits.fullyQualifiedName!T 
ought to give it to you.


Please note that fullyQualifiedName can return slightly different 
string than ClassInfo.name for templated types (typeinfo returns 
names that are fully expanded for eponymous templates while FQN 
function does not) and hence won't recommend mixing both of them 
toghether.


Best regards,
Alexandru.


Re: Translating Java into D

2019-11-16 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Friday, 15 November 2019 at 03:29:16 UTC, Heromyth wrote:

On Thursday, 14 November 2019 at 19:50:22 UTC, NonNull wrote:
Greetings, Java seems to be almost a subset of D in various 
ways.
No, it's not exactly right. Java is more powerful than D as for 
a language. Many things that Java can do can't be done by D. 
For example, reflection, full meta info for a type  in runtime, 
type deduction for a template, template member override.


See:
https://stackoverflow.com/questions/4829631/unusual-generic-syntax-arrays-stringaslist
https://www.baeldung.com/java-executor-service-tutorial

Has there been any work done to automatically translate Java 
source into D?


We ported some projects in Java by hand.


Regarding template member override. Generics in java are mainly 
compile time thing that boils down to auto generated casts when 
working with generic types (in bytecode), and therefore a 
templated method in java is actually a standard method that just 
works with Object class under the hood, hence it is possible to 
override in implementor of interface/class. It can be done in D 
too you'll just need to strip out generics part in method 
declaration and just use casts from root Object for worst case.


Also what do you mean by "type deduction for a template"?

Best regards,
Alexandru.


Re: Alternative to C++ macro in D

2019-11-03 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Sunday, 3 November 2019 at 16:55:36 UTC, Vinod K Chandran 
wrote:

Hi all,
I can do this in C++.
#include 
using namespace std ;

#define end };
#define log(x)  cout << x << endl
#define wait std::cin.get()


int main() {
log("Trying to avoid the visual clutter aused by closing 
curly braces") ;

string myStr = "Now, code looks more elegant" ;
log(myStr) ;
wait ;
end
How can i do this in D ? Especially the " #define end }; ". 
I've tried " alias end = } " but didn't worked.
Edit : How can add syntax highlighting and coloring in code 
posted on this comment ?


If this is about logging functionality, check 
std.experimental.log package, it contains all necessary logging 
functionality.


About macros there aren't any similar to preprocessor macros in 
c/c++, however you can replace them with three options depending 
on your needs:


1. Just a simple function in conjunction eith ctfe: 
https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe

2. string mixins: https://dlang.org/articles/mixin.html
3. template mixins: https://dlang.org/spec/template-mixin.html

I'd say number 2 should be suitable for your example given you'd 
like to inject statements into body of some function.


Best regards,
Alexandru.


Re: Alternative to C++ macro in D

2019-11-03 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Sunday, 3 November 2019 at 17:02:30 UTC, Vinod K Chandran 
wrote:
On Sunday, 3 November 2019 at 16:55:36 UTC, Vinod K Chandran 
wrote:

Hi all,
I can do this in C++.
#include 
using namespace std ;

#define end };
#define log(x)  cout << x << endl
#define wait std::cin.get()


int main() {
log("Trying to avoid the visual clutter aused by closing 
curly braces") ;

string myStr = "Now, code looks more elegant" ;
log(myStr) ;
wait ;
end
How can i do this in D ? Especially the " #define end }; ". 
I've tried " alias end = } " but didn't worked.
Edit : How can add syntax highlighting and coloring in code 
posted on this comment ?


How can i edit my post ? There is no button or link to edit my 
post.


You can't, web version is just a frontend for mailing list.

Best regards,
Alexandru.


Converting stringized array to dstring[]

2019-02-24 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi everyone,

I've stumbled on another possible bug:
-
import std.stdio;
import std.conv;

void main() {
"[  \"test\"  ]".to!(dstring[]).writeln;
}
-

It gives following error:
-
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(222): Error: 
template std.conv.toImpl cannot deduce function from argument 
types !(dstring[])(string), candidates are:
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(493):
std.conv.toImpl(T, S)(S value) if (isImplicitlyConvertible!(S, T) 
&& !isEnumStrToStr!(S, T) && !isNullToStr!(S, T))
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(607):
std.conv.toImpl(T, S)(ref S s) if (isStaticArray!S)
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(623):
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, 
T) && is(typeof(S.init.opCast!T()) : T) && !isExactSomeString!T 
&& !is(typeof(T(value
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(674):
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, 
T) && is(T == struct) && is(typeof(T(value
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(723):
std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, 
T) && is(T == class) && is(typeof(new T(value
/dlang/dmd/linux/bin64/../../src/phobos/std/conv.d(222):
... (11 more, -v to show) ...
onlineapp.d(5): Error: template instance 
`std.conv.to!(dstring[]).to!string` error instantiating

-

Link to code: https://run.dlang.io/is/ymJXFc

Any idea why we don't support dstring/string -> dstring[] 
conversion?
Funny enough, wstring and simple string to wstring[] is working 
as expected.


Thank you,
Alexandru.


template alias argument accepts only class/interface types.

2019-02-23 Thread Alexandru Ermicioi via Digitalmars-d-learn
Perhaps I missed somewhere, but it seems that you can pass only 
classes or interfaces to alias argument of a template. Trying to 
pass another type (such as int, int[]) yields an error.


Example of issue:

void test(alias T)(int o) {
import std.stdio;
writeln("coo");
}

void main() {
int i;
test!(Object[])(0);
}


Try pass Object or IFoo and everything compiles perfectly.
Link to example: https://run.dlang.io/is/jqr9Zi

According to 
https://dlang.org/spec/template.html#TemplateAliasParameter, 
simple types and arrays are excluded from the list of supported 
"alias X" arguments. I'm wondering why do we have such 
limitation? Is there any reasoning at limiting primitive types 
and arrays?


Thank you,
Alexandru.



Cannot dispose const array?

2018-08-08 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi Dlang community!

I've stumbled on an interesting issue with allocators. It seems 
that we can't get disposed of arrays with const or immutable 
data. Consider example below:


Link: https://run.dlang.io/is/frnQI8

import std.stdio;
import std.range;
import std.algorithm;
import std.experimental.allocator;
import std.experimental.allocator.mallocator;

void main(string[] args) {
const(int)[] values = Mallocator.instance.makeArray!(const 
int)([1, 2, 3, 4]);

writeln(values);

Mallocator.instance.dispose(values);
}


We'd get following error:
/dlang/dmd/linux/bin64/../../src/phobos/std/experimental/allocator/package.d(2398):
 Error: function 
std.experimental.allocator.mallocator.Mallocator.deallocate(void[] b) shared is 
not callable using argument types (const(int)[]) shared
/dlang/dmd/linux/bin64/../../src/phobos/std/experimental/allocator/package.d(2398):
cannot pass argument array of type const(int)[] to parameter void[] b

onlineapp.d(11): Error: template instance 
`std.experimental.allocator.dispose!(shared(Mallocator), 
const(int))` error instantiating


Is it expected to not be able to dispose out of immutable or 
const data, or it is a bug that should be fixed?


Regards,
Alexandru.


scope variable values assigned to non-scope this.placeholder

2018-08-06 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi Dlang community!

I've been playing with dip1000 and scope storage class and 
stumbled upon a strange error that I can't to understand yet. 
Here is minimized version of code that generates the error:


The link: https://run.dlang.io/is/rg2Odu
--
import std.stdio;
import std.range;
import std.algorithm;
@safe:
class C {
const int*[] placeholder;

this(scope int*[] values) {
this.placeholder = values;
}
}

void main()
{
auto array = iota(0, 20).map!((int i) => new int(i)).array;

auto c = new C(array);

writeln(c.placeholder.map!(p => *p));
}
--

I'm not sure what I'm doing wrong, but from what I understand it 
should check 'this' lifetime to lifetime of scoped 'values' and 
error only in case when passed value has shorter lifetime than 
the container itself.


I'll be thankful if someone could explain what is wrong with this 
example.


Regards,
Alexandru.


Re: Function signature testing with is expression.

2017-12-17 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Sunday, 17 December 2017 at 16:19:00 UTC, ag0aep6g wrote:
On Sunday, 17 December 2017 at 14:44:15 UTC, Alexandru Ermicioi 
wrote:

Suppose:

struct F {
static void foo(T)(T i, int o) {}
}

enum bool check(T) = is(F.foo!T == void function(Z, int), Z);

enum correct = check!int;


Upon running it will return false, though, by logic is 
expression could deduce that F.foo is conformat to function 
signature in check test.


Here, `F.foo!T` is the function itself, not its type. You 
forgot `typeof`.


It is interesting that it will not work with global functions 
as well:



void foo(int i, double d) {};
enum bool check = is(typeof(foo) == void function(int, 
double));



It will be as well evaluated to false.


Write `typeof()` to make it work.

There are two kinds of function types in D:

1) "Proper" function types, e.g. `typeof(foo)` which gets 
printed as "void(int i, double d)", and
2) function pointer types, e.g. `typeof()` which gets 
printed as "void function(int i, double d)".


As you see, the second kind is the one you're comparing 
against. I don't think you can use the first kind directly in 
an IsExpression. The first kind is really rather useless, as 
far as I know. Argubaly, the language would be nicer without it.


Thanks for help, ag0aep6g and Ali.

Now it is more clear why it didn't work. Although I did try to 
use FunctionTypeOf, which failed, and it seems due to explanation 
about two kinds of function types. It seems that FunctionTypeOf 
returns first kind which does not work with is expression, and 
not second.

See the example (first line):

--
import std.traits;

struct T {
static void coo(M)(M e, int i);
}

void main() {
	pragma(msg, is(FunctionTypeOf!(!int) == void function(Z, 
int), Z));
	pragma(msg, is(FunctionTypeOf!(!X) == void function(X, 
int), X));

pragma(msg, is(typeof(!int) == void function(Z, int), Z));
pragma(msg, is(typeof(!X) == void function(X, int), X));
}
--

If run, first line will return false (even without &).

The initial question was related actually to another thing that 
I've tried to do, which is pattern matching on templated 
functions. It failed, see line 2, and 4.


It seems that now it is impossible to do pattern matching on 
templates, only on instantiated types.
Is there any possibility to check the internals of a template 
without instantiating it?
It would be good for using Policy pattern where you want for 
example to test passed policy, has a templated function with a 
desired signature for it.


Function signature testing with is expression.

2017-12-17 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi,

Have someone tried to test a function against a signature using 
is expression?


Suppose:

struct F {
static void foo(T)(T i, int o) {}
}

enum bool check(T) = is(F.foo!T == void function(Z, int), Z);

enum correct = check!int;


Upon running it will return false, though, by logic is expression 
could deduce that F.foo is conformat to function signature in 
check test.


It is interesting that it will not work with global functions as 
well:



void foo(int i, double d) {};
enum bool check = is(typeof(foo) == void function(int, double));


It will be as well evaluated to false.

So, the question is, is it I'm doing something wrong, that it 
doesn't work, or is it not implemented?
If not implemented, what simple and short alternatives are 
available?


Thanks.


ddoc and method overriding.

2017-08-12 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi all,

Having a trivial example such as:

```D
class Foo {
/**
 * A documentation info
**/
void fancy();
}

class Moo {
override void fancy();
}
```

Is there a way to tell ddoc to use Foo.fancy documentation block 
for overriding Moo.fancy method?


Thx.


Re: ddoc: Can I escape a colon?

2017-02-26 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Thursday, 23 February 2017 at 21:04:39 UTC, Nick Sabalausky 
(Abscissa) wrote:

Suppose I want ddoc output to include this line:

--
Note: Blah blabbety blah
--

But the colon causes "Note" to be considered a section header. 
Is there a way to escape the ":" so that it's displayed as 
expected, but doesn't trigger a section?


You can put a space before : and ddoc, or ddox won't treat it as 
a section.

-
Note : Blah blabbety blah
-


code.dlang.org package readme.md

2017-01-03 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hi all.

How it is possible to show readme.md from github repository in 
code.dlang.org for a particular project?


Thanks.


Re: delegate passed in annotation struct cannot be invoked.

2016-12-30 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Thursday, 29 December 2016 at 21:29:47 UTC, Stefan Koch wrote:

ldc accepts invalid code there.
But it might be that dmd 2.071.2 did that as well.
If so It will be fixed as soon as ldc updates the front-end 
version.


Nope, tried with dmd v2.071.2 and it gives same error as v2.072.1.
I think I'll add a bug report to ldc, about not emitting the 
error.


Thanks for help.


Re: delegate passed in annotation struct cannot be invoked.

2016-12-29 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch wrote:

It's a delegate and not function.
Therefore it will get a frame-ptr regardless, without checking 
if it is needed or not, or if there is a frame to point to.

Since there is no frame to point to you get the error.
At least this is my guess.
Make the delegate a function and the error should disappear.


Yep, making it a function, will eliminate the problem.
Though what I'm also curious is why on LDC it compiles and runs, 
while on DMD it does not?
Should it be registered as a bug on issues.dlang.org, or at ldc 
bug tracker?


delegate passed in annotation struct cannot be invoked.

2016-12-29 Thread Alexandru Ermicioi via Digitalmars-d-learn

Given code below:
import std.stdio;

struct Annotation {
public int delegate(int) dg;
}

void main() {
import std.traits;

__traits(getAttributes, Cls)[0].dg(20).writeln;
}

@Annotation(delegate int(int d) {
return d;
})
class Cls {

void method() {

}
}

Dmd will complain with following statement for the delegate 
passed in annotation:
src/app.d(13,13): Error: delegate app.__dgliteral6 is a nested 
function and cannot be accessed from D main.


GDC will just throw internal compiler exception:
src/app.d: In function ‘D main’:
src/app.d:20:2: internal compiler error: in get_frame_for_symbol, 
at d/d-codegen.cc:3981

  __traits(getAttributes, Cls)[0].dg(20).writeln;
  ^

LDC will not argue, and compile it flawlessly, and return 20 as 
expected.


So the question, is the dmd error correct behavior?
If so, how the delegate is nested, and what is context that it is 
nested in?


DMD version is: v2.072.1
LDC version is: v1.1.0 based on v2.071.2 and LLVM 3.8.1
GDC version is: 6.2.1 20161215


__traits(getOverloads, Type, member) order of elements in tuple.

2016-08-22 Thread Alexandru Ermicioi via Digitalmars-d-learn

Good day.

In current implementation of dmd/ldc/gdc, does this trait 
guarantee, that the order of elements returned in tuple, is same, 
in several calls of it on same Type and member?


Also, is guaranteed that in future versions of dmd, the order of 
elements won't change?


Re: Sequence separation

2016-08-21 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Wednesday, 17 August 2016 at 19:38:22 UTC, Engine Machine 
wrote:
Well, the is does work and that probably is the best solution. 
I don't mind the extra type at this point. Of course, a library 
solution for this type of stuff would be nice. I'd rather not 
have to even use a type but rather use arrays:

[a,b,[c,d]].


Maybe you can use Tuple from std.typecons, instead of custom 
structs, that group the arguments.


Ex:

alias seqWithSubSeq = AliasSeq!(a, b, Tuple!(c, d))

http://dlang.org/phobos/std_typecons.html#.Tuple


Re: Rebind template

2016-08-21 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Saturday, 20 August 2016 at 22:18:57 UTC, Engine Machine wrote:
On Saturday, 20 August 2016 at 22:11:40 UTC, Engine Machine 
wrote:

Is there a way to rebind the arguments of a template?

template foo(X)
{
   // X is like A!(a,b,c)
   Y = Rebind!(X,d,e,f);
   // Y is like A!(d,e,f);
}

foo(A!(a,b,c));

?


I'd also be happy if I could just remove the last element from 
A.


template EraseLast(X)
{
// returns A!(a,b) when X = A!(a,b,c)
}


Check for ApplyLeft and ApplyRight in std.meta, maybe it can help 
you.


http://dlang.org/phobos/std_meta.html#.ApplyLeft
http://dlang.org/phobos/std_meta.html#.ApplyRight


Ascii string literal.

2016-05-06 Thread Alexandru Ermicioi via Digitalmars-d-learn

Good day,

Is it possible somehow to convert implicitly a string literal 
into an ubyte array?

For example:

void do(immutable(ubyte)[] asciiString) {
// Do something with ascii string.
}

And from another section of code, calling it like:

do("Some ascii string");
---

If no, is there an us-ascii string literal that consists of 
ubytes and not chars?


It's just in some of my code should work only with ascii strings, 
and it will be cumbersome to convert to ubyte array a string 
literal each time a function accepting an ubyte array is called.


Thank you.


Wrap array into a range.

2016-03-05 Thread Alexandru Ermicioi via Digitalmars-d-learn
I have to pass an array to a function that accepts an input 
range. Therefore I need to transform somehow array into an input 
range.


Is there a range that wraps an array in standard library?


Re: Why getting private member fails using getMember trait in a template?

2015-09-29 Thread Alexandru Ermicioi via Digitalmars-d-learn
On Saturday, 26 September 2015 at 10:10:39 UTC, Alexandru 
Ermicioi wrote:

Suppose we have, two modules:

module testOne;

[...]


So, is this behavior correct?
If yes, then why?


Why getting private member fails using getMember trait in a template?

2015-09-26 Thread Alexandru Ermicioi via Digitalmars-d-learn

Suppose we have, two modules:

module testOne;

import std.traits;

template getMember(alias T, string member) {
alias getMember = Identity!(__traits(getMember, T, member));
}

module app;
import testOne;
import std.traits;

class TestOne {

private {
int property;
}

public {
int func() {
return 0;
}
}
}


template getMember(alias T, string member) {
alias getMember = Identity!(__traits(getMember, T, member));
}

void main() {
pragma(msg, fullyQualifiedName!(__traits(getMember, TestOne, 
"property")));
pragma(msg, fullyQualifiedName!(app.getMember!(TestOne, 
"property")));
pragma(msg, fullyQualifiedName!(testOne.getMember!(TestOne, 
"property")));

}

First two statements execute and I get fully qualified name, 
while the third one fails with next error (dmd version v2.067.1):
src/testOne.d(6): Error: class app.TestOne member property is not 
accessible
src/app.d(26): Error: template instance 
testOne.getMember!(TestOne, "property") error instantiating
src/app.d(26):while evaluating pragma(msg, 
fullyQualifiedName!(testOne.getMember!(TestOne, "property")))


Re: Template detection

2015-09-22 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Tuesday, 22 September 2015 at 15:37:32 UTC, Meta wrote:
On Sunday, 13 September 2015 at 08:26:55 UTC, Alexandru 
Ermicioi wrote:

Hello,

Given:

class SomeClass {

public {
void someSimpleMethod() {}

template setOfTemplatedMethods(Type) {
void templatedMethodOne() {}
void templatedMethodTwo() {}
}
}
}

Is there a way to detect at compile time if a member of 
class/struct is a template? (in the example above, if 
setOfTemplatedMethods is a template).


You can use __traits(isTemplate, ).


Thx. Didn't know that there is such trait available.

On page http://dlang.org/traits.html it's not present.


Re: Template detection

2015-09-22 Thread Alexandru Ermicioi via Digitalmars-d-learn

On Sunday, 13 September 2015 at 09:29:13 UTC, Enamex wrote:
On Sunday, 13 September 2015 at 08:26:55 UTC, Alexandru 
Ermicioi wrote:

Hello,

Given:

class SomeClass {

public {
void someSimpleMethod() {}

template setOfTemplatedMethods(Type) {
void templatedMethodOne() {}
void templatedMethodTwo() {}
}
}
}

Is there a way to detect at compile time if a member of 
class/struct is a template? (in the example above, if 
setOfTemplatedMethods is a template).


There's this: 
http://stackoverflow.com/questions/5483381/test-if-an-alias-is-a-template-in-d-2-0


and it should work with 'member templates' OK.


Thx for the provided link.

I've tried to implement version from the stackoverflow answer, 
and run against tests provided in another answer to the question 
in link, and failed.


With dmd version 2.067.1 this implementation fails at
static assert(! isTemplate!(FooS!int.func!float) );
static assert(! isTemplate!(FooS!int.bar) );
for .func it requires "this" (an value of type FooS, or 
isTemplate fails to instantiate).

and for .bar it just fails (isTemplate detects it as a template).

I've found another way to detect if a symbol is a template.
The idea is that for a not instantiated template you can get with 
allMembers trait the list of members in template, but you can't 
access them using getMembers trait since the template is not 
instantiated yet.
So if there is a symbol that has members which cannot be accessed 
using getMember (generates an error) then this is a template!


template allMembers(alias Type) {
alias allMembers = TypeTuple!(__traits(allMembers, Type));
}

template anyAccessible(alias Container, T...) {
static if (T.length > 1) {
enum bool anyAccessible = anyAccessible!(Container, T[0 
.. $ / 2]) || anyAccessible!(Container, T[$ / 2 .. $]);

} else static if (T.length == 1) {
enum bool anyAccessible = __traits(compiles, 
getMember!(Container, T[0]));

} else {
enum bool anyAccessible = false;
}
}

template isTemplate(alias T) {
static if ( // check if symbol has members
__traits(compiles, TypeTuple!(__traits(allMembers, T)))
&& !T.stringof.startsWith("module ", "package ")
) {
enum bool isTemplate =
(allMembers!(T).length > 0)
&& !anyAccessible!(T, allMembers!T);
} else {
enum bool isTemplate = false;
}
}

It passes almost all tests except for:
static assert(! isTemplate!((int x){return x;}) );
static assert(! isTemplate!(std) );
static assert(! isTemplate!(core) );

I don't know how but in this cases, compiler attempts to parse 
true branch of static if, even if the expression in static if is 
false.
For lamda function allMembers trait fails to get the members and 
an error is created by compiler.
For std, and core packages isTemplate evaluates to true even if 
expression from static if is false.


Is such behavior of static if correct (tested also with ldc 
compiler, same results)?


If there are other test cases, would be glad if they are posted 
here (to improve the accuracy of template detection).


Tests are:

struct FooS(T) {
struct Inner {}
struct Inner2(string U="!(") {}
int func(U)() { return 0; }
int bar;
}
FooS!int foo;

class FooC { int x; }
union FooU { int x;}
enum FooE { x }
interface FooI { int x(); }

template FooT(T) {
struct Inner {}
struct Inner2(string U="!(") {}
int func(U)() { return 0; }
int bar;
}

static assert(! isTemplate!0 );
static assert(! isTemplate!"0" );
static assert(! isTemplate!0.0f );
static assert(! isTemplate!'0' );
static assert(! isTemplate!'!' );
static assert(! isTemplate!"module std.stdio" );
static assert(! isTemplate!null );
static assert(! isTemplate!true );
static assert(! isTemplate!__FILE__ );
static assert(! isTemplate!__LINE__ );
static assert(! isTemplate!([]) );
static assert(  isTemplate!FooS );
static assert(! isTemplate!(FooS!int) );
static assert(  isTemplate!(FooS!int.func) );
static assert(! isTemplate!(FooS!int.func!float) );
static assert(! isTemplate!(FooS!int.bar) );
static assert(! isTemplate!(FooS!int.Inner) );
static assert(  isTemplate!(FooS!int.Inner2) );
static assert(! isTemplate!(FooS!int.Inner2!"?") );
static assert(  isTemplate!FooT );
static assert(! isTemplate!(FooT!int) );
static assert(  isTemplate!(FooT!int.func) );
static assert(! isTemplate!(FooT!int.func!float) );
static assert(! isTemplate!(FooT!int.bar) );
static assert(! isTemplate!(FooT!int.Inner) );
static assert(  isTemplate!(FooT!int.Inner2) );
static assert(! isTemplate!(FooT!int.Inner2!"?") );
static assert(! isTemplate!foo );
static assert(  isTemplate!(foo.func) );
static assert(  isTemplate!isTemplate );
static assert(! isTemplate!(isTemplate!isTemplate) );
static assert(! isTemplate!FooC );
static assert(! isTemplate!FooU );
static assert(! isTemplate!FooE );
static assert(! isTemplate!FooI );
static assert(! isTemplate!((int 

Template detection

2015-09-13 Thread Alexandru Ermicioi via Digitalmars-d-learn

Hello,

Given:

class SomeClass {

public {
void someSimpleMethod() {}

template setOfTemplatedMethods(Type) {
void templatedMethodOne() {}
void templatedMethodTwo() {}
}
}
}

Is there a way to detect at compile time if a member of 
class/struct is a template? (in the example above, if 
setOfTemplatedMethods is a template).