Re: Troublemaker dmd 2.061 - Templates?
On 01/05/2013 08:52 AM, David wrote: http://dpaste.dzfl.pl/d703d10e (code from above) That is equally incomplete. :) Could you please also provide surrounding code that would help us reproduce this issue? At the minimum, the import lines and a main() function will be helpful. Thank you, Ali
Re: Troublemaker dmd 2.061 - Templates?
Am 05.01.2013 17:57, schrieb Ali Çehreli: On 01/05/2013 08:52 AM, David wrote: http://dpaste.dzfl.pl/d703d10e (code from above) That is equally incomplete. :) Could you please also provide surrounding code that would help us reproduce this issue? At the minimum, the import lines and a main() function will be helpful. Thank you, Ali 16k codebase: https://github.com/Dav1dde/BraLa/tree/master/brala/network/packets util.d contains this code, server.d and client.d mix it in, it's used like in parse_packet (util.d)
Re: Troublemaker dmd 2.061 - Templates?
LOL
mixin template get_packets_mixin(alias Module) {
template get_packets() {
alias NoDuplicates!(get_packets_impl!(get_members!())) get_packets;
}
template get_members() {
alias TypeTuple!(__traits(allMembers, Module)) get_members;
}
private template get_packets_impl(T...) {
static if(__traits(compiles, mixin(T[0]).id)) {
// pragma(msg, PacketTuple!(mixin(T[0]), mixin(T[0]).id));
// pragma(msg, get_packets_impl!(T[1..$]));
alias TypeTuple!(PacketTuple!(mixin(T[0]), mixin(T[0]).id),
get_packets_impl!(T[1..$])) get_packets_impl;
} else {
// pragma(msg, get_packets_impl!(T[1..$])); // --
alias TypeTuple!(get_packets_impl!(T[1..$])) get_packets_impl;
}
}
private template get_packets_impl() {
alias TypeTuple!() get_packets_impl;
}
template PacketTuple(T, ubyte b) {
alias T cls;
alias b id;
}
auto parse_packet(ubyte id)(Stream s) {
alias staticIndexOf!(id, staticMap!(extract_id, get_packets!()))
id_index;
static if(id_index 0) {
static assert(false, Invalid packet with id: ~
toStringNow!id);
} else {
return get_packets!()[id_index].cls.recv(s);
}
}
pragma(msg, get_packets_impl!(__traits(allMembers, Module)));
}
With this pragma: pragma(msg, get_packets_impl!(T[1..$]));
outcommented, I get _error_, but if I let it in, everything compiles.
I have no idea if I should laugh or cry.
Customizing ddoc from cmd-line
I seem to be unable to customize DDoc from the command line. Suppose the sources are in src, docs in doc. Here is my command line (Win7 if that matters): dmd -D -Dddoc doc/my.ddoc src/main.d Nothing happens... What I would like to do is to add a style sheet as described in http://dlang.org/ddoc.html. Isn't it not possible from the cmdline or do I something wrong here ? How to make it working ? Peter
Why is immutable not possible as a result of a reduce expression?
Hi, just playing around with the functional capabilities of D. One concept of the pure functional programming is that variables should not be reassigned, so the best(?) way to assure this is using immutable: immutable auto gen = sequence!(n); immutable auto seq = take(gen,10); immutable auto filtered = filter!(a % 3 == 0 || a % 5 ==0)(seq); immutable auto sum = reduce!(a+b)(filtered); but the last line gives a compiler error: Error: template instance std.algorithm.reduce!(a+b).reduce!(immutable(FilterResult!(unaryFun,immutable(Take!(immutable(Sequence!(n,Tuple!( error instantiating It compiles and run as expected if I remove the immutable constraint on the reduce expression. So what is happening here? I thought reduce will create a new data structure containing the resulting values like filter and other operations too? That seems not to be the case, maybe someone could give me a deeper understanding of this. Thanks in advance Michael
Re: Customizing ddoc from cmd-line
Am 05.01.2013, 20:23 Uhr, schrieb Peter Sommerfeld nore...@rubrica.at: Nothing happens... Sorry, I was imprecise. Of course, the executable as well as the html was generated but my.ddoc had no effect. Peter
Re: Why is immutable not possible as a result of a reduce expression?
On 2013-52-05 20:01, Michael Engelhardt m...@mindcrime-ilab.de wrote: Hi, just playing around with the functional capabilities of D. One concept of the pure functional programming is that variables should not be reassigned, so the best(?) way to assure this is using immutable: immutable auto gen = sequence!(n); immutable auto seq = take(gen,10); immutable auto filtered = filter!(a % 3 == 0 || a % 5 ==0)(seq); immutable auto sum = reduce!(a+b)(filtered); but the last line gives a compiler error: Error: template instance std.algorithm.reduce!(a+b).reduce!(immutable(FilterResult!(unaryFun,immutable(Take!(immutable(Sequence!(n,Tuple!( error instantiating It compiles and run as expected if I remove the immutable constraint on the reduce expression. So what is happening here? I thought reduce will create a new data structure containing the resulting values like filter and other operations too? That seems not to be the case, maybe someone could give me a deeper understanding of this. The reason is that ranges may not be immutable or const. Ranges need to be mutated (popFront) to be iterable, and your filtered range cannot be mutated, by virtue of being immutable. I'm surprised that seq and filtered work, but I guess there may be specializations that circumvent the problem. In other words, remove immutable from the first three lines, and the program should compile. A little details is that immutable auto is unnecessary, as immutable implies auto (the details are more complex, but that's the short version). -- Simen
is(...) with alias this
Hi!
I just read the David's post
http://forum.dlang.org/thread/kc9e74$bg7$1...@digitalmars.com
This code worked with dmd 2.060:
import std.stdio;
import std.traits;
struct OhWhy(S) {
S[] arr;
alias arr this;
}
void main() {
static assert(isArray!(OhWhy!(float)));
}
But fails with dmd 2.061:
ss.d(10): Error: static assert (isArray!(OhWhy!(float))) is false
(same happens with alias this to static arrays and
isArray/isStaticArray)
Is this intended or a regression? If latter, I'll submit a
bug-ticket.
When I read this I understood that I don't know what should return
is(OhWhy!float unused == T[],T)
Of course OhWhy!float implicit convertable into float[].But on
the other hand
is with == (not :) should check the type without conversions.
What do you think?
DMD 2.060 HEAD evaluate is(OhWhy!float unused == T[],T) - true
Re: Why is immutable not possible as a result of a reduce expression?
On Saturday, 5 January 2013 at 20:09:24 UTC, Simen Kjaeraas wrote: The reason is that ranges may not be immutable or const. Ranges need to be mutated (popFront) to be iterable, and your filtered range cannot be mutated, by virtue of being immutable. I'm surprised that seq and filtered work, but I guess there may be specializations that circumvent the problem. No, they just make the erroneous assumption that copying strips immutablity. There are cases where this is true, but not always. The *only* time when this is true is with arrays, where immutable(T[]) can be copied to a immutable(T)[]. Even then, the compiler strips to top immutable of the type implicitly, so no extra code should be rolled out for it anyways... IMO, the only sensible behavior when calling auto filter!(immutable R)(r) would be to return an immutable Filter!R initialized with r... ...but you'd have to do it with the actual immutable constructor. Simply creating a Filter!R and then castng it to immutable would also be wrong. Ditto for all other range types. I'll try and review them.
template function. test array parameter length
I have a template function that must work with an array of float
values.
something like this:
void foo(T : A[], A)(auto ref T arg)
if(is(A == float))
{
...
}
Array may be static or dynamic. But the length of the array must
be 16 or 32. How can i test length value?
Re: is(...) with alias this
I think the alias this transformation is done 'before' any usual conversion. I guess it's a real replacement inside the code (I'm not sure how to explain my feeling). But in any case, since OhWhy!(float) type is ... OhWhy!(float), I agree this should fail.
Re: is(...) with alias this
On Saturday, 5 January 2013 at 22:09:45 UTC, Philippe Sigaud wrote: I think the alias this transformation is done 'before' any usual conversion. I guess it's a real replacement inside the code (I'm not sure how to explain my feeling). But in any case, since OhWhy!(float) type is ... OhWhy!(float), I agree this should fail. Agreed. This warrants a ticket in bugzilla.
Re: template function. test array parameter length
thanks)
Re: template function. test array parameter length
On Sat, Jan 5, 2013 at 10:50 PM, ref2401 refacto...@gmail.com wrote:
I have a template function that must work with an array of float values.
something like this:
void foo(T : A[], A)(auto ref T arg)
if(is(A == float))
{
...
}
Array may be static or dynamic. But the length of the array must be 16 or
32. How can i test length value?
For a dynamic array, its type is T[] and the length is a known only at
runtime (by definition). You can test it with a runtime test, but not with
a template constraint.
For a static array T[n], n is part of the type so you can indeed filter the
bad ones during compilation.
Using std.traits and std.range:
import std.array;
import std.traits;
import std.range;
void foo(T)(auto ref T arg)
if ( isDynamicArray!T is(ElementType!T == float)
|| isStaticArray!T (T.length == 16 || T.length == 32)
is(ElementType!T == float))
{}
void main()
{
float[] dynamicArr;
float[3] staticArr1 = [0.0,1.0,2.0];
float[16] staticArr2;
foo(dynamicArr);
//foo(staticArr1); // fails
foo(staticArr2);
}
Or, if you prefer using the is() expression:
void bar(T)(auto ref T arg)
if ( is(T _ == U[], U)
|| is(T _ == U[n], U, size_t n) (n == 16 || n == 32))
{}
void main()
{
float[] dynamicArr;
float[3] staticArr1 = [0.0,1.0,2.0];
float[16] staticArr2;
bar(dynamicArr);
//bar(staticArr1); // fails
bar(staticArr2);
}
Auto-Implemented properties
i was trying to make a D template to mimic auto-implemented
properties in c#.
I think i got it to work but when i tried to give the template a
more meaning full name like AutoImplementedProperty i get a
compile error a.title is not an lvalue.
Is this a bug?
Is there a more suitable way of doing this?
c# e.g:
class Bar
{
public string Title { get; set; }
}
my attempt:
class Bar
{
alias autoproperty!(string, get, set) title
}
template autoproperty(T, args...)
{
import std.typetuple;
@property
{
private T _name;
static if (args.length)
{
static if (staticIndexOf!(get, args) -1)
{
public T autoproperty()
{
return _name;
}
}
static if (staticIndexOf!(set, args) -1)
{
public void autoproperty(T value)
{
_name = value;
}
}
}
}
}
void main(string[] args)
{
Bar a = new Bar();
a.title = asf;
writefln(a.title);
return;
}
Re: Auto-Implemented properties
Hi Michael, your code works for me (DMD 2.061, Linux), with a semicolon after the alias in class Bar. Also, use writeln, not writefln, because writefln assumes the first parameter is the formatting string.
Re: Auto-Implemented properties
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud wrote: Hi Michael, your code works for me (DMD 2.061, Linux), with a semicolon after the alias in class Bar. Also, use writeln, not writefln, because writefln assumes the first parameter is the formatting string. Why would you want get/set though when D offers property functions? The argument of if your public attribute becomes private, then code breaks is invalid in D.
Re: Auto-Implemented properties
On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud wrote: Hi Michael, your code works for me (DMD 2.061, Linux), with a semicolon after the alias in class Bar. Also, use writeln, not writefln, because writefln assumes the first parameter is the formatting string. Thanks for the tip. Does it work for you if you rename the template to AutoImplementedProperty?
Re: Why is immutable not possible as a result of a reduce expression?
On 01/05/2013 12:09 PM, Simen Kjaeraas wrote: A little details is that immutable auto is unnecessary, as immutable implies auto (the details are more complex, but that's the short version). It is true that the OP does not need auto when there is already immutable but does immutable really imply auto, or are they orthogonal? Ali P.S. I had wrongly assumed that D's auto was the same as C++11's auto and that it came from automatic type deduction. That is not true in D. As in C and old C++, D's auto comes from automatic storage duration. We still use it for automatic type deduction to make the syntax happy when there is no other keyword to put to the left of the symbol.
Re: Auto-Implemented properties
On 01/05/2013 03:25 PM, michaelc37 wrote: On Saturday, 5 January 2013 at 22:53:44 UTC, Philippe Sigaud wrote: Hi Michael, your code works for me (DMD 2.061, Linux), with a semicolon after the alias in class Bar. Also, use writeln, not writefln, because writefln assumes the first parameter is the formatting string. Thanks for the tip. Does it work for you if you rename the template to AutoImplementedProperty? I confirm this: Any name other than the seemingly magical autoproperty causes the following errors: Error: a.title is not an lvalue Error: expression has no value Ali
Re: Auto-Implemented properties
On 01/05/2013 04:32 PM, Ali Çehreli wrote: I confirm this: Any name other than the seemingly magical autoproperty causes the following errors: Error: a.title is not an lvalue Error: expression has no value I retract that! :) That happens when I replace only the two autoproperty with AutoImplementedProperty. There is no error when I replace all four! :) Ali
Re: Why is immutable not possible as a result of a reduce expression?
On Saturday, January 05, 2013 16:18:51 Ali Çehreli wrote: On 01/05/2013 12:09 PM, Simen Kjaeraas wrote: A little details is that immutable auto is unnecessary, as immutable implies auto (the details are more complex, but that's the short version). It is true that the OP does not need auto when there is already immutable but does immutable really imply auto, or are they orthogonal? Ali P.S. I had wrongly assumed that D's auto was the same as C++11's auto and that it came from automatic type deduction. That is not true in D. As in C and old C++, D's auto comes from automatic storage duration. We still use it for automatic type deduction to make the syntax happy when there is no other keyword to put to the left of the symbol. D's auto _is_ automatic type deduction like in C++11. It's just that const, immutable, and enum also deduce the type if you don't give it (with the addition of making the type const or immutable in the cases of const and immutable). auto a = 1; const c = 1; immutable i = 1; enum e = 1; all do type inferrence and all work just fine. - Jonathan M Davis
Re: Why is immutable not possible as a result of a reduce expression?
On 01/05/2013 04:59 PM, Jonathan M Davis wrote: D's auto _is_ automatic type deduction like in C++11. It must have changed in the last couple of years. I see that the documentation is now different: http://dlang.org/attribute.html#auto It now says The auto attribute is used when there are no other attributes and type inference is desired. It used to be not the case. The historical evidence is still there in compiler error messages: auto auto a = 1; Error: redundant storage class 'auto' ;) Ali
