Re: Simple code sample of Nesting Structures. I'm I doing something illegal here?
On Saturday, 22 November 2014 at 20:57:07 UTC, WhatMeWorry wrote: auto bottom = NestedBottom(2, ['d','o','g']); That 'auto' is the problem. You want 'this.bottom = ...' instead.
Re: Recursive template
Slightly simpler:
struct SomeType(K, V) {}
alias X(V) = V;
alias X(V, K...) = SomeType!(K[0], X!(V, K[1 .. $]));
That's a recurring pattern to get used to: aliasing away to one
of the parameters in a terminal and/or degenerate case. Also:
that an empty tuple matches no parameter more exactly than a
tuple parameter. I know that's not at all obvious, but it's what
I've found to be the case; so when K[1 ..$] above ends up as the
empty tuple (that is, when all K have been exhausted), the
template for X(V) will be the more exact match.
Re: Code fails with linker error. Why?
In the original you are casting an int to a pointer type, which is legitimate (although rarely a good idea). The other side of the matter is simply precedence. cast(T)a.b; Is really the same as: cast(T)(a.b);
Re: Novice web developer trying to learn D
There's Adam Ruppe's excellent D Cookbook available here: https://www.packtpub.com/application-development/d-cookbook And since you specifically said web developer I hope you're looking at vibe.d: http://vibed.org/
Re: Auto-add static field when inherit // mixins, templates?
class A
{
string getName(this Klass)()
{
return Klass.stringof;
}
}
class B : A
{}
void main()
{
import std.stdio;
auto a = new A;
auto b = new B;
writeln(a.getName());
writeln(b.getName());
}
##
This is about as close as you're going to get without some
hackery.
Re: delegates GC allocations
On Wednesday, 20 August 2014 at 15:17:52 UTC, Ola Fosheim Gr wrote: non-static nested functions are effectively delegates as it needs a context pointer to parent stack frame. Only if it is recursive. Or if it refers to any state of the parent function.
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 07:43:27 UTC, Uranuz wrote:
I don't know why I use D enough long but I did not remember
this fact.
Sometimes we get spoiled by all the amazing/nifty things that do
work, and expect comparable things like this to Just Work. To be
honest, at first I didn't see any issue in what you were doing
either...
One thing you could do in the meantime is to use an instantiator
function. This works just fine:
auto pair(F, S)(F f, S s)
{
return Pair!(F, S)(f, s);
}
void main()
{
auto p = pair(Category.first, first);
writeln(p);
}
Re: Enum type deduction inside templates is not working
On Friday, 27 June 2014 at 14:27:46 UTC, H. S. Teoh via Digitalmars-d-learn wrote: Try this: Get out of my head!
Re: import except one?
On Friday, 27 June 2014 at 05:26:09 UTC, Puming wrote: On Thursday, 26 June 2014 at 08:02:24 UTC, bearophile wrote: Puming: I'm using scriptlike, which imports everything from std.process for convienience, but I also need to import another module, which contains a class `Config`, it conflicts with std.process.Config. I don't actually need std.process.Config, but I need many other symbols in scriptlike and std.process. What I want to achieve is to import ALL symbols from scriptlike EXCEPT std.process.Config, something like: ```d import scriptlike: !Config; A similar idea is present in Haskell, but it was refused by Walter. Thanks :-) I wander what was the rationale behind Walter's rejection. IMHO if we have a selective filter mechanism for imports, the complement exclude mechinism works as well. But of cause we are not that far yet, final, nothrow, pure and others don't have their complements either. The use of scriptlike is going to cause you similar problems, it's not for a fine tuning of imports. The problem is that we don't have a complete mechanism to fine tuning the imports. Selective filtering is only half of the cake. Bye, bearophile I wasn't in that particular discussion, but based on history, I imagine Walter's argument was probably along the lines of just use a static import for both modules and use either aliasing or FQN's for the symbols you need. That and inner scope imports.
Re: close program by code
On Thursday, 26 June 2014 at 11:07:37 UTC, Rene Zwanenburg wrote: They won't. Same for module destructors. If you need those to work, another option is to throw some custom Exception type which is only caught in main. I really wish this wasn't the answer, but for some programs I've had to resort to it myself. For at least one I've defined an Exception type that carries a status code payload to be returned by main. D needs its own exit(). There's been this request in the bugzilla since 2009: https://issues.dlang.org/show_bug.cgi?id=3462
Re: Using attributes inside template instantiation
UDA's are compile-time metadata associated with a specific declaration. So in something like: @foo int x; The @foo is attached to x, but is not part of the type.
Re: Using two flags in conditonal compilation (version)
version(DigitalMars) version = DMDAsm;
version(LDC) version = DMDAsm;
version(DMDAsm) asm {
//dmd/ldc asm here
}
version(GDC) asm {
//gdc asm here
}
http://dlang.org/version.html#VersionSpecification
Re: Using attributes inside template instantiation
On Wednesday, 25 June 2014 at 17:21:21 UTC, H. S. Teoh via Digitalmars-d-learn wrote: The term attribute is a bit confusing, especially since property is also used in the language to refer to something completely different. A better term is perhaps annotation. The @foo is an annotation on x, but its type is just int. Agree whole-heartedly. I usually introduce people to the idea by referring to them as annotations, which they understand quickly, then later tell them that it's called an attribute because of reasons no one knows. I get funny looks, but at least they comprehend it. I'm not so sure it's too late to get the terminology changed, though, and I sincerely hope it will.
Re: next!T
On Saturday, 7 June 2014 at 02:23:18 UTC, Andrew Edwards wrote: This function now works for all types except dstring. This remains a problem I cannot figure out. The error code is as follows: $ rdmd -unittest textnext /usr/share/dmd/src/phobos/std/conv.d(3293): Error: cannot modify immutable expression c /usr/share/dmd/src/phobos/std/conv.d(3297): Error: cannot modify immutable expression c /usr/share/dmd/src/phobos/std/conv.d(2904): Error: template instance std.conv.parseElement!(immutable(dchar), string) error instantiating io.d(64):instantiated from here: parse!(immutable(dchar)[], string) textnext.d(12):instantiated from here: next!(immutable(dchar)[]) io.d(64): Error: template instance std.conv.parse!(immutable(dchar)[], string) error instantiating textnext.d(12):instantiated from here: next!(immutable(dchar)[]) textnext.d(12): Error: template instance io.next!(immutable(dchar)[]) error instantiating Failed: [dmd, -unittest, -v, -o-, textnext.d, -I.] This error is report failure on dstring at [2] but I fully expected them at [1]. I've looked at implementation of isSomeString() (https://github.com/D-Programming-Language/phobos/blob/master/std/traits.d#L5178) and clearly dstrings are addressed in the implementation there. What exactly am I missing in my understanding? Any assistance/advice is appreciated. Thanks, Andrew I got it working here by putting an else before the second static-if.
Re: Creating new types from tuples.
On Friday, 6 June 2014 at 23:44:04 UTC, Evan Davis wrote:
Hello,
I'm looking to use the Tuple type as a way of generating types
to represent data in a send recieve connection pair. I created
a template to try this:
template s_to_c(UDP packetType) {
static if (packetType == UDP.ping) {
alias Tuple!() s_to_c;
} else static if (packetType == UDP.connect) {
alias Tuple!(byte) s_to_c;
} else static if (packetType == UDP.keep_alive) {
alias Tuple!() s_to_c;
}
}
(UDP is a enum with packet types.)
This works, but it also means that s_to_c(UDP.ping) is the same
type as s_to_c(UDP.keep_alive). I want to be forced to
distinguish between types, even if they contain the same
fields, so that
recieve(
(s_to_c!(UDP.ping) value) { },
(s_to_c!(UDP.keep_alive) value) { }
)
isn't an error.
Any suggestions are welcome, and thanks for any help,
-Evan Davis
Is there any reason you couldn't (or would rather not) use
structs rather than tuples?
Re: next!T
On Saturday, 7 June 2014 at 03:21:49 UTC, Andrew Edwards wrote: Wow. Sometimes you really cannot see the things you type no matter how long you stare at it. Thank you soo much. No problem. I only noticed when I re-typed it by hand to study the flow, and instinctively added the else out of habit and wondered why I was getting no errors. :) Started thinking it was one of those this is an error, but only on Thursdays kind of things. Anyway, since the bugged code was freaking out in the second, unreachable, return statement, it leads me to thinking whether we could provide some sane way for the compiler to point out such things (unreachable returns). It would have made this case, and ones like it, more obvious.
Re: enums
On Saturday, 31 May 2014 at 22:45:32 UTC, bearophile wrote: Chris Nicholson-Sauls: Good... I was starting to fear I was the only one. In general you can't fix the names in a language because you always find someone that likes the ones present :) I think enum is a bad name for the purpose of defining manifest constants, but I don't think this will change. Bye, bearophile In a perfect world, sure, we'd have a different name for it; I'm not saying I love it, just that it makes sense in my head. I've sometimes thought 'alias' could have worked as well, especially now with the a=b syntax. alias DEFAULT_PORT = 11020; But, then we exchange one set of brow raisers for another set. In the absence of #define, there probably is no achievable ideal. :)
Re: support for unicode in identifiers
On Sunday, 1 June 2014 at 22:26:42 UTC, Vlad Levenfeld wrote: I was pretty happy to find that I could use mu and sigma when writing statistical routines, but I've found that for more obscure non-ascii characters the support is hit or miss. For example, none of the subscripts are valid characters, but I can use superscript n as well as dot-notation for derivatives. I'm using dmd 2.065. What's the story behind the scenes? Is there a rationale behind the supported/unsupported or is it happenstance? Is there anywhere I can find a list of supported characters? The allowed characters are those defined as universal in ISO/IEC 9899 (the C standard). It's a pretty long list, but almost only alphas; I'm actually surprised you got superscripts and some other things to work. As I understand it, the intention was a) be like C99, and b) allow things like using stærð rather than staerdh. I'm not sure usage like yours was even thought about, although I'd concede that it seems reasonable.
Re: enums
On Saturday, 31 May 2014 at 22:13:35 UTC, monarch_dodra wrote: On Saturday, 31 May 2014 at 21:21:59 UTC, Paul D Anderson wrote: 'enum' as a manifest constant keyword has been an unpopular decision from its introduction. Everybody agrees that it should be changed. Everybody but Walter I find enum makes sense. Good... I was starting to fear I was the only one.
