Re: Real simple question... for good programmers
On 10/22/22 5:53 PM, WhatMeWorry wrote: string[] tokens = userSID.output.split!isWhite; writeln("tokens = ", tokens); tokens = ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""] Is there a clever way that I can discard all the extra null strings in the resultant string array? I've been playing with isControl, whitespace, etc. Ready to rip my hair out. Try just split without the `isWhite`. If you look at the docs, you will see: "When no delimiter is provided, strings are split into an array of words, using whitespace as delimiter. Runs of whitespace are merged together (no empty words are produced)." -Steve
Re: Real simple question... for good programmers
On Saturday, 22 October 2022 at 21:53:05 UTC, WhatMeWorry wrote: string[] tokens = userSID.output.split!isWhite; writeln("tokens = ", tokens); [...] Is there a clever way that I can discard all the extra null strings in the resultant string array? Easiest way is to use [`filter`][1]. Here's an example: ```d import std.algorithm: splitter, filter; import std.uni: isWhite; // or use std.ascii for non-unicode input import std.array: array; import std.stdio: writeln; string exampleText = "Hello 123-456-ABCx\ny\tz\r\nwvu goodbye"; void main() { string[] tokens = exampleText .splitter!isWhite .filter!(t => t.length > 0) .array; writeln("tokens = ", tokens); } ``` I've also used the lazily-evaluated [`splitter`][2] instead of the eagerly-evaluated `split`, to avoid allocating a temporary array unnecessarily. [1]: https://phobos.dpldocs.info/std.algorithm.iteration.filter.html [2]: https://phobos.dpldocs.info/std.algorithm.iteration.splitter.3.html
Re: Real simple question... for good programmers
On Saturday, 22 October 2022 at 22:01:09 UTC, Enjoys Math wrote: On Saturday, 22 October 2022 at 21:53:05 UTC, WhatMeWorry wrote: string[] tokens = userSID.output.split!isWhite; writeln("tokens = ", tokens); tokens = ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""] Is there a clever way that I can discard all the extra null strings in the resultant string array? I've been playing with isControl, whitespace, etc. Ready to rip my hair out. Why not `strip`? Works on ranges: https://dlang.org/phobos/std_algorithm_mutation.html#.strip Strip won't work because it only works on the beginning and ends of the range. What you want is `remove`. See my other MWE post.
Re: Real simple question... for good programmers
__MWE Code:__ ``` module DlangForumsMWE; import std.stdio; import std.algorithm.mutation; int main() { //string[] tokens = userSID.output.split!isWhite; //writeln("tokens = ", tokens); auto tokens = ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""]; writeln("Before:\n", tokens); writeln(); tokens = tokens.remove!(x => x == ""); writeln("After:\n", tokens); readln(); return 0; } ``` __Outputs:__ ``` Before: ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""] After: ["SID", "S-1-5-21-3823976785-3597194045-4221507747-1779"] ```
Re: Real simple question... for good programmers
On 10/22/22 14:53, WhatMeWorry wrote: > > > string[] tokens = userSID.output.split!isWhite; > writeln("tokens = ", tokens); Could you please show minimal compilable code that demonstrates the issue. I spent some time with some guesses but failed (to get my code to compile with std.array.split). Ali P.S. Sorry for also sending email.
Re: Real simple question... for good programmers
On Saturday, 22 October 2022 at 21:53:05 UTC, WhatMeWorry wrote: string[] tokens = userSID.output.split!isWhite; writeln("tokens = ", tokens); tokens = ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""] Is there a clever way that I can discard all the extra null strings in the resultant string array? I've been playing with isControl, whitespace, etc. Ready to rip my hair out. Why not `strip`? Works on ranges: https://dlang.org/phobos/std_algorithm_mutation.html#.strip
Real simple question... for good programmers
string[] tokens = userSID.output.split!isWhite; writeln("tokens = ", tokens); tokens = ["SID", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "S-1-5-21-3823976785-3597194045-4221507747-1779", "", "", "", "", "", "", "", ""] Is there a clever way that I can discard all the extra null strings in the resultant string array? I've been playing with isControl, whitespace, etc. Ready to rip my hair out.
Re: DMD -i option, simple question...
On Friday, 20 November 2020 at 03:06:37 UTC, WhatMeWorry wrote: The "..when this option is enabled..." is exactly the behavior I want, but how is it enabled? Is there an "all inclusive pattern" that I'm missing. dmd -i yourfile.d that's the default it is describing when you don't specify any pattern.
DMD -i option, simple question...
The DMD forum mentions internal design. This is more of a beginner usage question. - from Compiler Switches - -I=directory Look for imports also in directory -i[=pattern ] Enables "include imports" mode, where the compiler will include imported modules in the compilation, as if they were given on the command line. By default, when this option is enabled, all imported modules are included except those in druntime/phobos The "..when this option is enabled..." is exactly the behavior I want, but how is it enabled? Is there an "all inclusive pattern" that I'm missing.
Re: Hopefully a simple question...
On Friday, 13 January 2017 at 16:56:43 UTC, WhatMeWorry wrote: I'm converting some C++ and glm code to D and gl3n. And I'm stumped at the following line. GLboolean CheckCollision(BallObject , GameObject ) // AABB - Circle collision { // Get center point circle first glm::vec2 center(one.Position + one.Radius); . . . } one.Position is a vec2 (x and y) whereas Radius is a GLfloat // my D code statement vec2 center2 = one.position + one.radius; // D code with gl3n returns Error: incompatible types for ((one.position) + (one.radius)): 'Vector!(float, 2)' and 'float' I agree with the D code. A vec and scalar can't be added together. So why (or how) is the glm code working? I looked at https://github.com/g-truc/glm project source, but I'm not even sure where to start? Thanks If you're doing game dev stuff I'd highly recommend using/taking a look at https://github.com/d-gamedev-team/ and in particular using https://github.com/d-gamedev-team/gfm/ as your math library. It appears to support what you want https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/vector.d#L53-59
Re: Hopefully a simple question...
On Friday, 13 January 2017 at 16:56:43 UTC, WhatMeWorry wrote: A vec and scalar can't be added together. So why (or how) is the glm code working? The C++ source disagrees: https://github.com/g-truc/glm/blob/master/glm/detail/type_vec2.hpp#L219 It works via operator overloading, and adding a scalar simply means adding it to all vector components. In your case, you may get away by simply using the types in `core.simd`, such as `float2` instead of your `Vector` template. Otherwise, D operator overloading is way more elegant in D than in C++, see https://dlang.org/spec/operatoroverloading.html.
Re: Real Simple Question?
On 10/22/16 5:34 PM, WhatMeWorry wrote: On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis wrote: On Saturday, October 22, 2016 20:35:27 WhatMeWorry via Digitalmars-d-learn wrote: [...] Just put it in a separate module and then import it. e.g. file: mypackage/constants.d == module mypackage.constants; GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . ]; I would make this: immutable GLfloat[] vertices If you can do it. This will make it so it's a) accessible from pure functions, and b) will not create a separate thread-local copy for each thread (if you use threading). Ok, but now I'm getting these error in my new mypackage/constants.d ...\common\vertex_data.d(5,15): Error: undefined identifier 'GLfloat' ...\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' It's difficult to know why without more code hints, but it appears that vertex_data.d needs to import the module that defines these types. Note that if you want to have an imported module provide these definitions from another module, then you need to public import the module. So for instance (guessing at your code, since I don't know what you have for import statements): mypackage/my_types.d: alias GLfloat = float; alias vec3 = GLfloat[3]; mypackage/constants.d: public import mypackage.my_types; // this allows importers of constants.d to see the types used GLfloat[] vertices = ... vertex_data.d: import mypackage.constants; // pulls in definitions from my_types.d -Steve
Re: Real Simple Question?
On Saturday, 22 October 2016 at 21:34:36 UTC, WhatMeWorry wrote: On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis wrote: [...] Ok, but now I'm getting these error in my new mypackage/constants.d ..\common\vertex_data.d(5,15): Error: undefined identifier 'GLfloat' ..\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' Is there a way to just suck in the text from say a .txt file that would not be compiled before inclusion in main.d? You could format your array in JSON format, and read it in your program. That could be another solution.
Re: Real Simple Question?
On Saturday, October 22, 2016 21:34:36 WhatMeWorry via Digitalmars-d-learn wrote: > Ok, but now I'm getting these error in my new > mypackage/constants.d > > ..\common\vertex_data.d(5,15): Error: undefined identifier > 'GLfloat' > ..\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' mypackage/constants.d needs to import the modules for any of the types it's using, otherwise it doesn't know about them. Modules are not textually included like header files are in C++ (compilation times would be _way_ worse if they were), so a module only has access to what it imports, and it's not affected by anything that imports it. > Is there a way to just suck in the text from say a .txt file that > would not be compiled before inclusion in main.d? String imports is a feature, but then you end up with multiple copies of the array in your program instead of one, and string imports are almost always the wrong solution. - Jonathan M Davis
Re: Real Simple Question?
On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis wrote: On Saturday, October 22, 2016 20:35:27 WhatMeWorry via Digitalmars-d-learn wrote: [...] Just put it in a separate module and then import it. e.g. file: mypackage/constants.d == module mypackage.constants; GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . ]; == file: main.d == import mypackage.constants; void main() { auto v = vertices; } == Probably the key thing to remember is that when you compile your program, all of the modules that are part of your program rather than a separate library need to be compiled into it. Simply importing them isn't enough - though using either rdmd or dub make that easier. This is the official documentation's page on modules: http://dlang.org/spec/module.html This is the chapter from Al's book that covers modules: http://ddili.org/ders/d.en/modules.html And you'd almost certainly benefit from simply reading Ali's book as a whole: http://ddili.org/ders/d.en/index.html - Jonathan M Davis Ok, but now I'm getting these error in my new mypackage/constants.d ..\common\vertex_data.d(5,15): Error: undefined identifier 'GLfloat' ..\common\vertex_data.d(53,12): Error: undefined identifier 'vec3' Is there a way to just suck in the text from say a .txt file that would not be compiled before inclusion in main.d?
Re: Real Simple Question?
On Saturday, October 22, 2016 20:35:27 WhatMeWorry via Digitalmars-d-learn wrote: > This is probably so simple that there's no example anywhere. > > Basically, I've got a huge array definition (see below) which I > reuse over and over again in different projects. > > GLfloat[] vertices = > [ > // Positions // Texture Coords > -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, > 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, > . > (lots and lots of values) > . > > I'd like to place this one array into a separate file and just > include it with a one line statement in many projects. I'm > thinking mixins and/or imports but then if I knew how to do this, > I wouldn't be asking. > > Thanks in advance. Just put it in a separate module and then import it. e.g. file: mypackage/constants.d == module mypackage.constants; GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . ]; == file: main.d == import mypackage.constants; void main() { auto v = vertices; } == Probably the key thing to remember is that when you compile your program, all of the modules that are part of your program rather than a separate library need to be compiled into it. Simply importing them isn't enough - though using either rdmd or dub make that easier. This is the official documentation's page on modules: http://dlang.org/spec/module.html This is the chapter from Al's book that covers modules: http://ddili.org/ders/d.en/modules.html And you'd almost certainly benefit from simply reading Ali's book as a whole: http://ddili.org/ders/d.en/index.html - Jonathan M Davis
Real Simple Question?
This is probably so simple that there's no example anywhere. Basically, I've got a huge array definition (see below) which I reuse over and over again in different projects. GLfloat[] vertices = [ // Positions // Texture Coords -0.5f, -0.5f, -0.5f, 0.0f, 0.0f, 0.5f, -0.5f, -0.5f, 1.0f, 0.0f, . (lots and lots of values) . I'd like to place this one array into a separate file and just include it with a one line statement in many projects. I'm thinking mixins and/or imports but then if I knew how to do this, I wouldn't be asking. Thanks in advance.
Re: simple question about using dub to import CyberShadow's aeutils
On Saturday, 3 January 2015 at 12:08:16 UTC, Vladimir Panteleev wrote: On Saturday, 3 January 2015 at 11:58:48 UTC, Laeeth Isharc wrote: import ae.utils; ae.utils is a package, perhaps you meant to import ae.utils.xml? aha. schoolboy error on my part. thank you for your help, and especially for writing such a useful library and sharing it with the world. Laeeth.
Re: simple question about using dub to import CyberShadow's aeutils
On Saturday, 3 January 2015 at 11:58:48 UTC, Laeeth Isharc wrote: import ae.utils; ae.utils is a package, perhaps you meant to import ae.utils.xml?
Re: simple question about function call syntax
On Monday, 18 August 2014 at 16:30:13 UTC, Nikolay wrote: I found this code sample in vibe: void connect(NetworkAddress addr) { enforce(.connect(m_ctx.socketfd, addr.sockAddr, addr.sockAddrLen) == 0, Failed to connect UDP socket.~to!string(getLastSocketError())); } What does mean .connect? Where I can find description of this syntax (dot + function name)? . is the module-scope. Use it to dis-ambiguate between a module-global symbol and a function local symbol with same name.
Re: simple question about function call syntax
On Mon, 18 Aug 2014 16:30:12 + Nikolay via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: What does mean .connect? Where I can find description of this syntax (dot + function name)? right here: http://dlang.org/expression.html#PrimaryExpression language documentation rulez! ;-) signature.asc Description: PGP signature
Re: simple question about function call syntax
right here: http://dlang.org/expression.html#PrimaryExpression language documentation rulez! ;-) Yes I found it. Correct link: Module Scope Operator http://dlang.org/module.html
Re: simple question about function call syntax
On Tue, 19 Aug 2014 03:36:26 + Nikolay via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: right here: http://dlang.org/expression.html#PrimaryExpression language documentation rulez! ;-) Yes I found it. Correct link: Module Scope Operator http://dlang.org/module.html my link is correct too. ;-) quote: .Identifier Identifier is looked up at module scope, rather than the current lexically nested scope. but your is better. signature.asc Description: PGP signature
Re: A simple question
On Friday, 16 November 2012 at 01:00:58 UTC, Walter Bright wrote: On 11/15/2012 4:11 PM, Stugol wrote: am I likely to be told to fuck off again? I haven't seen Bernard lately, so probably not. I'm still about. Bernard was certainly out of line with that remark Absolutely. I let the NG get under my skin too much. I'm trying to be a reformed man!
Re: A simple question
On 11/16/2012 4:08 AM, Nick Sabalausky wrote: On Fri, 16 Nov 2012 01:11:18 +0100 As for your specific issue, there's a few different factors: 1. Like other have already said, all the files need to be sent to DMD together (possibly by using RDMD) or, if not that, then at least their objects all need to be sent to the linker together. I realize you're using VisualD and therefore have reason to expect it to be taken care of automatically, but since something obviously might be going awry in that regard, you'll need to take it up with the VisualD developer. If you're nice to him, he might even be glad to help out. 2. If there is indeed an actual bug in the compiler or linker (instead of either VisualD or your project's VisualD settings), and you want it addressed promptly (keeping in mind this is a non-commercial venture and you're not paying anyone for support, so therefore there are NO timeframe guarantees), then it will help greatly if you provide a test case (and file it in the bug tracker: http://d.puremagic.com/issues/ ) which fully demonstrates the problem *without* having any reliance on any tool other than the compiler/linker itself. Yes, this means dealing with the command line. 3. The linker's error message needs to be better (as many people have already agreed with you on). The linker itself is written in highly-optimized assembly (and is in the process of being - very meticulously - converted to C for easier maintenance, as a stepping stone to it eventually moving to D), so changes to it *will be* slow. What *can* be done though, is to pipe its output through a D demangler, and in fact I think someone's already made such a tool. If you're not willing to use a direct command line to do that, then you can put in a request (not a demand) with the VisualD dev to have such functionality incorporated into VisualD. Or, although this may be a stretch, you could even offer to help incorporate the change to VisualD yourself. 4. I'm not sure I even see a specific problem in that thread that hasn't been addressed. First of all, it looks like your DFL problem was solved by including DFL in your VisualD project's dependencies. Secondly, I'm not getting your error when I try this: http://forum.dlang.org/thread/souztdpadfefltnvc...@forum.dlang.org?page=2#post-djjkyaqnwlsquticjfmw:40forum.dlang.org Both of those files compile fine for me with DMD 2.060, and if I toss in a void main() {} I even get a working executable. Even though the discussion seems to have cooled down, I'd like to clarify a number of speculations: Visual D compiles the files that are added to the project, not anything imported as rdmd does (I think this does not scale for larger projects where you better use libraries for sub-projects). Visual D does not use incremental builds because this causes linker problems due to missing symbols. Judging from single file compilation it won't even reduce build times because import dependencies cause almost everything is compiled or at least semantically analyzed anyways (though this might be with my projects only). As of 0.3.34 Visual D demangles the linker output (if not explicitely disabled in the options).
Re: A simple question
On 16/11/12 05:15, Rob T wrote: On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote: Event_t e2;// Will compile! Yeah but that kinda blows, doesn't it? I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it, One of the oldest open enhancement requests is on this topic: http://d.puremagic.com/issues/show_bug.cgi?id=1012 I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.
Re: A simple question
Now I'm working that. Kenji Hara 2012/11/16 Don Clugston d...@nospam.com On 16/11/12 05:15, Rob T wrote: On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote: Event_t e2;// Will compile! Yeah but that kinda blows, doesn't it? I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it, One of the oldest open enhancement requests is on this topic: http://d.puremagic.com/issues/**show_bug.cgi?id=1012http://d.puremagic.com/issues/show_bug.cgi?id=1012 I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.
Re: A simple question
Done. https://github.com/D-Programming-Language/dmd/pull/1295 Kenji Hara 2012/11/16 kenji hara k.hara...@gmail.com Now I'm working that. Kenji Hara 2012/11/16 Don Clugston d...@nospam.com One of the oldest open enhancement requests is on this topic: http://d.puremagic.com/issues/**show_bug.cgi?id=1012http://d.puremagic.com/issues/show_bug.cgi?id=1012 I don't what the reason is. It'd be interesting to revive the patch there, and see if it passes the compiler test suite.
Re: A simple question
On 11/16/12, kenji hara k.hara...@gmail.com wrote: Done. https://github.com/D-Programming-Language/dmd/pull/1295 Have you seen this comment: On 11/16/12, jerro a...@a.com wrote: doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here?
Re: A simple question
On 2012-11-16 11:16, Andrej Mitrovic wrote: Have you seen this comment: On 11/16/12, jerro a...@a.com wrote: doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here? And my reply to that comment: Any place where a template and an instantiation is allowed it will default to a template. The user would then need to explicitly add !() to indicate an instantiation. In all other places, it will be an instantiation. I think in most cases using just a template is not allowed. -- /Jacob Carlborg
A simple question
When I post on these forums to ask for new features (e.g. iterators), you say that you won't be adding any new features at the moment, and that you are instead concentrating on making the language stable and usable. However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. So what the fuck's the point? D is a great language, and I really want to use it, but it doesn't work. And when I post here about its flaws and limitations, I get flamed.
Re: A simple question
On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote: When I post on these forums to ask for new features (e.g. iterators), you say that you won't be adding any new features at the moment, and that you are instead concentrating on making the language stable and usable. However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. So what the fuck's the point? D is a great language, and I really want to use it, but it doesn't work. And when I post here about its flaws and limitations, I get flamed. This forum isn't a bug tracking system. It is for discussion, in relation to bugs that means identifying it it really is a bug and deciding on the priority of that bug over other goals. To say that being told you won't see it any times soon is flaming is exaggeration. If you have a real example of flames then please do bring that forward, but there isn't much the community will be able to do about it. There is a lot of issues in D, selection isn't always objective and direction isn't well documented at this point. Many times it can seem a voice isn't being heard and suddenly its taken care of. Really you just need to convince one person it is of priority, that person will need the skill/initiative to implement it and submit the changes, and maybe that person is yourself. Luckily that list of people is growing and not shrinking.
Re: A simple question
On Thursday, 15 November 2012 at 22:43:22 UTC, Jesse Phillips wrote: To say that being told you won't see it any times soon is flaming is exaggeration. If you have a real example of flames then please do bring that forward, but there isn't much the community will be able to do about it. I was told to fuck off and to stop wasting everyone's time when I was just trying to discuss bugs in the language. If that's not a flame, I don't know what is. There is a lot of issues in D, selection isn't always objective and direction isn't well documented at this point. Many times it can seem a voice isn't being heard and suddenly its taken care of. Really you just need to convince one person it is of priority, that person will need the skill/initiative to implement it and submit the changes, and maybe that person is yourself. Luckily that list of people is growing and not shrinking. Well, last I heard, the two bugs I just mentioned weren't going to be fixed. So wtf?
Re: A simple question
On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote: However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. Please provide links to that statements and the respective Bugzilla issues. Otherwise, this is a quite … unsubstantial claim. David
Re: A simple question
On Thursday, 15 November 2012 at 23:56:49 UTC, David Nadlinger wrote: On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote: However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. Please provide links to that statements and the respective Bugzilla issues. Otherwise, this is a quite … unsubstantial claim. To clarify: My intent is not to be picky, but you make it sound like a legitimate bug report was dismissed without giving any reasons for that. I find it hard to imagine that this would be the case. David
Re: A simple question
On Thursday, 15 November 2012 at 23:56:49 UTC, David Nadlinger wrote: On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote: However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. Please provide links to that statements and the respective Bugzilla issues. Otherwise, this is a quite … unsubstantial claim. David I didn't use BugZilla, I posted on the forum. It was a few months ago. Feel free to search the forums for my name if you care. There aren't many threads with my name. As to the module bug, I refer you to this error I just received after trying to use D again after a long absence: Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\ I reported the above bug in this thread months ago: http://www.google.com/url?sa=trct=jq=stugolsource=webcd=1cad=rjaved=0CC8QFjAAurl=http%3A%2F%2Fwww.digitalmars.com%2Fd%2Farchives%2Fdigitalmars%2FD%2FIncomprehensible_compiler_errors_173731.htmlei=Z4OlUKqOO6Oi0QWir4DAAgusg=AFQjCNFlgFDSwgjBEWUA1SbimjMK6kNwFg Nothing has been done: the bug still exists. Coincidentally, this was the same thread I was told to fuck off in. Are these bugs likely to be addressed, or am I likely to be told to fuck off again?
Re: A simple question
On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote: As to the module bug, I refer you to this error I just received after trying to use D again after a long absence: Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\ That means the your custom module wasn't given on the final command line. The easiest way to build a D program is to put all your files on the command line at once: dmd main.d helper.d infinity/standard/api/windows.d [etc etc etc] And it should then spit out a working executable without much hassle. Any libraries you use should be on that command line too, add the .libs as well as your .ds.
Re: A simple question
On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote: Are these bugs likely to be addressed, or am I likely to be told to fuck off again? Ah, now things become clearer. The issue here is that what you are describing is not an actual bug, but the consequence of you not specifying one of the source files you imported as part of the compiler command (use rdmd if you don't want to deal with such things). Granted, the diagnostics for it are terrible, you just get to see the raw linker error message. It has been agreed on that usability issues such as this are important, particularly because they mostly affect newcomers and might scare them away. The issue just is that nobody has found the time to work on this yet – the main compiler devs intuitively tend to focus on the »meaty« issues which actually cause the language to behave incorrectly for _all_ users. Also, if you are used to working on compilers, error messages such as the one you posted are naturally easy to understand, which might lead to some perception bias regarding usability. In general, things such as this would be a great first problem to attack for somebody interesting in compiler development. David
Re: A simple question
On Friday, 16 November 2012 at 00:29:24 UTC, David Nadlinger wrote: Granted, the diagnostics for it are terrible, you just get to see the raw linker error message. This is potentially very easy to fix... $ cat demangle.d import core.demangle; import std.stdio; import std.regex; string dem(Captures!(char[], uint) m) { return demangle(m.hit).idup; } void main(string[] args) { if(args.length 1) { foreach(arg; args[1..$]) writeln(demangle(arg)); return; } foreach(line; stdin.byLine) { writeln(line.replace!dem(regex(_D[a-zA-Z0-9_]+, g))); } } $ cat /home/me/demangle_gcc #!/bin/bash exec gcc $* 21 | /home/me/demangle $ export CC=/home/me/demangle_gcc $ dmd test2.d test2.o: In function `_Dmain': test2.d:(.text._Dmain+0x34): undefined reference to `_D9something1A7__ClassZ' test2.d:(.text._Dmain+0x41): undefined reference to `something.A something.A.__ctor(int)' collect2: ld returned 1 exit status A little more readable than `_D9something1A6__ctorMFiZC9something1A'! core.demangle apparently has some bugs, but these simple little scripts help to beautify the linker output without actually changing anything. On Windows, the environment variable LINKCMD is used instead of CC. Other than that and other little details, I'm sure the same approach would work. Now, append CC=/home/me/demangle_gcc to your dmd.conf... and there's now no need to set the environment variable in your shell. So if we made those demangle scripts and put them in the zip with dmd, then changed dmd.conf to use the helper script (CC=%@P%demangle_gcc on linux, LINKCMD=demangle_link.bat on windows) and there you go, demangled linker output. A fancier script could detect things like ModuleInfo and give a helpful hint afterwards.
Re: A simple question
On Friday, 16 November 2012 at 00:20:00 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote: As to the module bug, I refer you to this error I just received after trying to use D again after a long absence: Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\ That means the your custom module wasn't given on the final command line. I'm using VisualD. I don't have a final command line. The easiest way to build a D program is to put all your files on the command line at once: dmd main.d helper.d infinity/standard/api/windows.d [etc etc etc] See above. (Yes, I know there will be a command line somewhere, but it's nothing to do with me) The point is, it says that kind of crap all the time. Even when it doesn't, if I take the MODULE statement out, it comes back. The module keyword is supposed to be optional.
Re: A simple question
On Friday, 16 November 2012 at 00:39:48 UTC, bearophile wrote: Stugol: Huh? This usually happens if I omit the module statement at the top of EVERY DAMN FILE (why???) but in this case I haven't omitted it, yet I'm still getting the error. ... What the HELL is this ModuleInfo, why is it necessary, why is it always missing when a module statement is not present, and why is it missing NOW? Even if the bugs actually exist, and aren't problems in what you are doing, posts that contain similar aggressiveness are less likely to be answered nicely. If you want nice answers, be first of all gentle yourself. I believe this post occurred *after* I had already been met with hostility.
Re: A simple question
On Friday, 16 November 2012 at 00:29:24 UTC, David Nadlinger wrote: On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote: Are these bugs likely to be addressed, or am I likely to be told to fuck off again? Ah, now things become clearer. The issue here is that what you are describing is not an actual bug, but the consequence of you not specifying one of the source files you imported as part of the compiler command (use rdmd if you don't want to deal with such things). Granted, the diagnostics for it are terrible, you just get to see the raw linker error message. No, this happens if I omit the optional MODULE statement at the top of the file as well. And, as I recall, at other times. In general, things such as this would be a great first problem to attack for somebody interesting in compiler development. How fascinating. Got anyone particular in mind?
Re: A simple question
On 11/15/2012 4:11 PM, Stugol wrote: am I likely to be told to fuck off again? I haven't seen Bernard lately, so probably not. Bernard was certainly out of line with that remark, but we try not to censor people here. Peoples' comments are their own responsibility.
Re: A simple question
On Friday, 16 November 2012 at 00:55:36 UTC, Stugol wrote: The point is, it says that kind of crap all the time. Even when it doesn't, if I take the MODULE statement out, it comes back. The module keyword is supposed to be optional. Oh, I see what's going on now. The module thing is only optional in simple cases, where the name has no dots and matches the filename. If you are using packages, the module line is required to get that full name registered in the file.
Re: A simple question
I believe this post occurred *after* I had already been met with hostility. That post was actually the very first post in the thread.
Re: A simple question
On Friday, 16 November 2012 at 01:14:18 UTC, Adam D. Ruppe wrote: The module thing is only optional in simple cases, where the name has no dots and matches the filename. If you are using packages, the module line is required to get that full name registered in the file. Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation. Yes, I read the documentation. All of it. Did I mention I really liked the language?
Re: A simple question
On Friday, 16 November 2012 at 02:00:05 UTC, Stugol wrote: Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation. It might not be clear, but it is there: http://dlang.org/module.html The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name. The parenthesis is important in this case - once the name is stripped of path, it only leaves a simple name, no more package info.
Re: A simple question
On Friday, 16 November 2012 at 02:22:32 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2012 at 02:00:05 UTC, Stugol wrote: Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation. It might not be clear, but it is there: http://dlang.org/module.html The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name. The parenthesis is important in this case - once the name is stripped of path, it only leaves a simple name, no more package info. I'm not quite sure what purpose the MODULE keyword serves in any case. I have a file Include.D\Infinity\Standard\Mixins\Event.d, but if I give it a module name of infinity.standard.event it doesn't work. I have to include the .mixins part. So what's the point? Also, I'm having difficulty specifying a default specialisation for a template class: class Event(TEventArgs : EventArgs = EventArgs) { } Usage: Event!() e1; // Works Event e2;// Won't compile How can I have Event be an alias for Event!EventArgs?
Re: A simple question
On Fri, 16 Nov 2012 01:11:18 +0100 Stugol stu...@gmx.com wrote: On Thursday, 15 November 2012 at 23:56:49 UTC, David Nadlinger wrote: On Thursday, 15 November 2012 at 21:25:03 UTC, Stugol wrote: However, when I post on these forums to ask for bugs to be fixed (e.g. the defective MODULE keyword, or the linker not supporting spaces in paths), you say that's not going to happen anytime soon. Please provide links to that statements and the respective Bugzilla issues. Otherwise, this is a quite … unsubstantial claim. David I didn't use BugZilla, I posted on the forum. It was a few months ago. Feel free to search the forums for my name if you care. There aren't many threads with my name. As to the module bug, I refer you to this error I just received after trying to use D again after a long absence: Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\ I reported the above bug in this thread months ago: http://www.google.com/url?sa=trct=jq=stugolsource=webcd=1cad=rjaved=0CC8QFjAAurl=http%3A%2F%2Fwww.digitalmars.com%2Fd%2Farchives%2Fdigitalmars%2FD%2FIncomprehensible_compiler_errors_173731.htmlei=Z4OlUKqOO6Oi0QWir4DAAgusg=AFQjCNFlgFDSwgjBEWUA1SbimjMK6kNwFg Nothing has been done: the bug still exists. Coincidentally, this was the same thread I was told to fuck off in. Are these bugs likely to be addressed, or am I likely to be told to fuck off again? You came in abusive right from the first post in the thread, continued making snide and contentious remarks even while *most* people were being polite (even *before* anyone got harsh with you), and you're continuing the abusiveness in parts of this thread, too. Maybe fuck off is overly harsh, but you certainly shouldn't be surprised that someone said it considering your consistently poor tone. What might be surprising though is that some of us are still willing to try to help. Additionally, issues *are* being fixed all the time. If your particular ones haven't been among them yet, well, them's the breaks. I have issues I've been patiently waiting for, too. So do other people. But being demanding certainly isn't going to get your issues addressed first. It's just going to piss people off and make them want to either ignore you or tell you to fuck off. As for your specific issue, there's a few different factors: 1. Like other have already said, all the files need to be sent to DMD together (possibly by using RDMD) or, if not that, then at least their objects all need to be sent to the linker together. I realize you're using VisualD and therefore have reason to expect it to be taken care of automatically, but since something obviously might be going awry in that regard, you'll need to take it up with the VisualD developer. If you're nice to him, he might even be glad to help out. 2. If there is indeed an actual bug in the compiler or linker (instead of either VisualD or your project's VisualD settings), and you want it addressed promptly (keeping in mind this is a non-commercial venture and you're not paying anyone for support, so therefore there are NO timeframe guarantees), then it will help greatly if you provide a test case (and file it in the bug tracker: http://d.puremagic.com/issues/ ) which fully demonstrates the problem *without* having any reliance on any tool other than the compiler/linker itself. Yes, this means dealing with the command line. 3. The linker's error message needs to be better (as many people have already agreed with you on). The linker itself is written in highly-optimized assembly (and is in the process of being - very meticulously - converted to C for easier maintenance, as a stepping stone to it eventually moving to D), so changes to it *will be* slow. What *can* be done though, is to pipe its output through a D demangler, and in fact I think someone's already made such a tool. If you're not willing to use a direct command line to do that, then you can put in a request (not a demand) with the VisualD dev to have such functionality incorporated into VisualD. Or, although this may be a stretch, you could even offer to help incorporate the change to VisualD yourself. 4. I'm not sure I even see a specific problem in that thread that hasn't been addressed. First of all, it looks like your DFL problem was solved by including DFL in your VisualD project's dependencies. Secondly, I'm not getting your error when I try this: http://forum.dlang.org/thread/souztdpadfefltnvc...@forum.dlang.org?page=2#post-djjkyaqnwlsquticjfmw:40forum.dlang.org Both of those files compile fine for me with DMD 2.060, and if I toss in a void main() {} I even get a working executable.
Re: A simple question
On Fri, 16 Nov 2012 03:55:53 +0100 Stugol stu...@gmx.com wrote: On Friday, 16 November 2012 at 02:22:32 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2012 at 02:00:05 UTC, Stugol wrote: Hmm, that makes a bit more sense now I guess. Funny, I don't remember seeing that rule when I read the documentation. It might not be clear, but it is there: http://dlang.org/module.html The ModuleDeclaration sets the name of the module and what package it belongs to. If absent, the module name is taken to be the same name (stripped of path and extension) of the source file name. The parenthesis is important in this case - once the name is stripped of path, it only leaves a simple name, no more package info. I'm not quite sure what purpose the MODULE keyword serves in any case. I have a file Include.D\Infinity\Standard\Mixins\Event.d, but if I give it a module name of infinity.standard.event it doesn't work. I have to include the .mixins part. So what's the point? It sounds like you're using something that does automatic dependency tracking, like RDMD (maybe VisualD uses RDMD behind the scenes?) The only way those *can* work is of the filename/path matches (othewrwise, if it needs to find a module named foo.bar.bat, it has no way to know where to find it if it's not in something named foo/bar/bat.d). In order to have module/package names that differ from the file/path names, the only way for that to work is if you pass those files in explicitly. Otherwise the compiler or build system would have to read every file on your computer hoping to find one that included the text module foo.bar.bat;. Naturally, that wouldn't be a good idea ;) Since it can be a pain to track all of your files manually, most people just follow the module/package name == file/path name convention so they can use an auto-dependency tool like RDMD. Also, I'm having difficulty specifying a default specialisation for a template class: class Event(TEventArgs : EventArgs = EventArgs) { } That would probably normally be: class Event(TEventArgs = EventArgs) { } Unless you really are requiring that TEventArgs must be either EventArgs or something derived from EventArgs. (Maybe you are?) Usage: Event!() e1; // Works Event e2;// Won't compile How can I have Event be an alias for Event!EventArgs? I think function templates are the only kind that can be instantiated without the !() part. So Event just refers to the template itself, not the class inside it. You may be able to do this: alias Event!() Event; But I don't know if that would result in a naming conflict.
Re: A simple question
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote: I'm not quite sure what purpose the MODULE keyword serves in any case. I have a file Include.D\Infinity\Standard\Mixins\Event.d, but if I give it a module name of infinity.standard.event it doesn't work. I have to include the .mixins part. So what's the point? I haven't used VisualD but I suspect it is assuming filenames based on import declarations. You don't have to do it this way though. If all the modules are passed on the one command, with a manual listing, the filename doesn't matter. It only uses the module line then. That's useful for times when your folder structure doesn't exactly match. Let me give you an example. For one of my work projects, we compile it differently for different clients. What I do is have a bunch of different configuration/customization files: custom_acme.d custom_bugs.d custom_daffy.d Each of these has the same module line: module myproduct.configuration; /* then various config variables and little customizations are next */ Then the main app never knows about the different clients. It just does import myproduct.configuration; and it all just works. Now, if I want to build the one for Acme, I do: dmd myapp.d custom_acme.d, and it is good. If I want to make the one for Bugs, I just do: dmd myapp.d custom_bugs.d and have their version. If they buy a source license, I can send just their file without changing anything else and without exposing any of the other client's custom code. It's something you might never need, but is really nice to have when it does come up. Also, I'm having difficulty specifying a default specialisation for a template class: Yea... even with default args, you still have to use the !() to tell it that you actually want the template instantiated. One option would be to do something like this: class EventBase(int a = 0) { } alias EventBase!(0) Event; void main() { EventBase!() e1; Event e2; } The alias line can include template arguments and then will work. But it needs to have a different name than the class itself so the names don't conflict. I don't think there's any other way... either has to be Event!() like you had, or use the alias like I did here.
Re: A simple question
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote: Also, I'm having difficulty specifying a default specialisation for a template class: class Event(TEventArgs : EventArgs = EventArgs) { } Usage: Event!() e1; // Works Event e2;// Won't compile How can I have Event be an alias for Event!EventArgs? I encountered this same wtf??? today. Apparently, even with a default type specified, you still have to put in a !(). I don't know what the reasoning was behind making this seeming redundancy a requirement, and it partially defeats the purpose of the default. IN my case I wanted the default type to be selected when left unspecified, but also to get rid of the !() requirement for a more natural appearance. I was planning on asking about this in the forums later. In any case, a simple work-a-round solution is to create an alias, for example: alias Event!() Event_t; // you may substitute Event_t with whatever type name you want Event_t e2;// Will compile! BTW, I come from a C++ background, and I found that certain parts of D were more difficult to learn perhaps because of my C++ background. I think this may be because I expected things like modules to work like .h files, but they don't, or I expected copy and move semantics to work the same way in D but they don't, or I expected structs and classes to be similar to what C++ provides, but they are in fact very different in terms of how they operate. The GC is another matter to get used to. The worse of it is a lack of detailed documentation. The very best thing you can do, is get a copy of The D Programming Language, there's also an on-line tutorial e-book, translated from Turkish into English over here http://ddili.org/ders/d.en/index.html but it is not yet fully translated. Good luck, and have some patience, you'll need it. --rt
Re: A simple question
On Friday, 16 November 2012 at 02:55:54 UTC, Stugol wrote: Also, I'm having difficulty specifying a default specialisation for a template class: class Event(TEventArgs : EventArgs = EventArgs) { } Usage: Event!() e1; // Works Event e2;// Won't compile How can I have Event be an alias for Event!EventArgs? I encountered this same wtf??? today. Apparently, even with a default type specified, you still have to put in a !(). I don't know what the reasoning was behind making this seeming redundancy a requirement, and it partially defeats the purpose of the default. IN my case I wanted the default type to be selected when left unspecified, but also to get rid of the !() requirement for a more natural appearance. I was planning on asking about this in the forums later. In any case, a simple work-a-round solution is to create an alias, for example: alias Event!() Event_t; // you may substitute Event_t with whatever type name you want Event_t e2;// Will compile! BTW, I come from a C++ background, and I found that certain parts of D were more difficult to learn perhaps because of my C++ background. I think this may be because I expected things like modules to work like .h files, but they don't, or I expected copy and move semantics to work the same way in D but they don't, or I expected structs and classes to be similar to what C++ provides, but they are in fact very different in terms of how they operate. The GC is another matter to get used to. The worse of it is a lack of detailed documentation. The very best thing you can do, is get a copy of The D Programming Language, there's also an on-line tutorial e-book, translated from Turkish into English over here http://ddili.org/ders/d.en/index.html but it is not yet fully translated. Good luck, and have some patience, you'll need it. --rt
Re: A simple question
On Friday, 16 November 2012 at 03:24:28 UTC, Nick Sabalausky wrote: Unless you really are requiring that TEventArgs must be either EventArgs or something derived from EventArgs. (Maybe you are?) I am. You may be able to do this: alias Event!() Event; But I don't know if that would result in a naming conflict. It does.
Re: A simple question
On Friday, 16 November 2012 at 03:32:06 UTC, Rob T wrote: I encountered this same wtf??? today. Apparently, even with a default type specified, you still have to put in a !(). I don't know what the reasoning was behind making this seeming redundancy a requirement, and it partially defeats the purpose of the default. IN my case I wanted the default type to be selected when left unspecified, but also to get rid of the !() requirement for a more natural appearance. I was planning on asking about this in the forums later. I agree. In any case, a simple work-a-round solution is to create an alias, for example: alias Event!() Event_t; // you may substitute Event_t with whatever type name you want Event_t e2;// Will compile! Yeah but that kinda blows, doesn't it? best thing you can do, is get a copy of The D Programming Language Good luck, and have some patience, you'll need it. Already got it somewhere, I think. And thanks.
Re: A simple question
On Friday, 16 November 2012 at 00:55:36 UTC, Stugol wrote: On Friday, 16 November 2012 at 00:20:00 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2012 at 00:11:19 UTC, Stugol wrote: As to the module bug, I refer you to this error I just received after trying to use D again after a long absence: Error 42: Symbol Undefined _D8infinity8standard3api7windows12__ModuleInfoZ d:\Documents\Programming\WindowsApp1\WindowsApp1\ That means the your custom module wasn't given on the final command line. I'm using VisualD. I don't have a final command line. So I'm going to have to claim this isn't a bug. And I know very little about how to address this issue with VisualD. For this reason I can't just give you an answer and instead I'll have to explain what you are being told so that you can find the missing piece. And as I don't know your experience it may sound as though I'm talking down to you. While this may seem a nitpick it is an important distinction. This is not a compiler error, it is from the linker. This means your program has has compiled successfully. The role of the linker is to find the machine code that can execute function calls you have made. From your link I see that your are using DFL, This is generally built into a library and then the linker is told to grab it. And I believe you'll need to tell it to build a windows executable: /exet:nt/su:windows:4.0 http://wiki.dprogramming.com/Dfl/SetupInstructions Onto the optional module statement. It is optional, but the name is derived from the directory and file structure at the place of compilation. So if VisualD does some incremental compilation from within a folder then the module will not be named what you are looking it up as. If this is the case then maybe the VisualD project has a bug here. I'm more incline to believe that you've attempted a combination of parts and just don't know how they fit together. The only way to improve on this situation is to write a tutorial on how to fit x, y and z together and make a whole. Generally this would come from the one trying to fit these pieces together as everyone has their own desired combinations. You may convince someone to give it a try, but you'll make it much more likely with a reduced case that demonstrates the problem, Run is not an entry into a program. I have had my share of difficult/impossible reductions, but I can't imagine you're very far with having run into this problem.
Re: A simple question
On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote: Event_t e2;// Will compile! Yeah but that kinda blows, doesn't it? I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it, but it's not that big of a deal because the power that alias gives you is amazing, and makes a problem like this go away once you start using it correctly. Also don't loose sight of the fact that D has a whole lot more that is good than is bad. I find the better a language is I actually get more picky about things that I don't like. A garbage language is, well garbage, so I tend to care much less if it sucks. So to see me complain, is actually a good thing, it means I like it and want to see if get better. --rt
Re: A simple question
I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it I don't know whether the language could be changed to support code like: struct Foo(){} Foo foo; but doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here?
Re: A simple question
On Friday, 16 November 2012 at 04:26:31 UTC, jerro wrote: I found it surprising or unintuitive that the !() is required, and I do want to know what is the reasoning behind it I don't know whether the language could be changed to support code like: struct Foo(){} Foo foo; but doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here? OK, now it makes sense, I figured there had to be a reason for the !(). Thanks for letting me know. --rt
Re: A simple question
On 2012-11-16 05:26, jerro wrote: I don't know whether the language could be changed to support code like: struct Foo(){} Foo foo; but doing that certainly would introduce some ambiguities. For example, consider this line: alias Foo Bar; Should Bar be a template or an instance of a template here? Any place where a template and an instantiation is allowed it will default to a template. The user would then need to explicitly add !() to indicate an instantiation. In all other places, it will be an instantiation. I think in most cases using just a template is not allowed. -- /Jacob Carlborg