Re: How to link *.a file on Windows?
On Friday, 23 September 2016 at 06:27:20 UTC, Brian wrote: On Thursday, 22 September 2016 at 17:09:38 UTC, Brian wrote: I use cygwin build a C++ lib file: libmemcached.a but, how to link it to my dub project? My plan: 1.I use cygwin build libmemcached.dll 2.use def tools export libmemcached.def 3.use VS2015 dev tools convert libmemcached.dll to libmemcached.lib 4.use coffimplib convert libmemcached.lib for D compiler but, this plan must dep dll file. how to static link libmemcached.lib? With dub, you can use the the 'libs' directive in your configuration file. See the Build Settings section a [1] if you are using JSON and [2] for SDL. If you manage to get your Cygwin-compiled libs to work with DMD successfully with this approach, please let us know. I was unable to get anything more than simple C libraries compiled by MinGW to work with DMD. [1] https://code.dlang.org/package-format?lang=json#build-settings [2] https://code.dlang.org/package-format?lang=sdl#build-settings
Re: combine dlang/tools into a single (or a few) binaries
On Saturday, 24 September 2016 at 05:19:39 UTC, rikki cattermole wrote: On 24/09/2016 5:11 PM, ketmar wrote: On Saturday, 24 September 2016 at 04:54:51 UTC, rikki cattermole wrote: I'd suggest dlangtools instead. exactly the thing virtually nobody will type even with autocompletion. Bingo! No reason for us to invite name conflicts. i bet someone already has dlangtools executable. i suggest NaIswgm0Z7A3YmK.
Re: combine dlang/tools into a single (or a few) binaries
On 24/09/2016 5:11 PM, ketmar wrote: On Saturday, 24 September 2016 at 04:54:51 UTC, rikki cattermole wrote: I'd suggest dlangtools instead. exactly the thing virtually nobody will type even with autocompletion. Bingo! No reason for us to invite name conflicts.
Re: Unum II announcement
On Wednesday, 17 August 2016 at 16:03:22 UTC, H. S. Teoh wrote: On Wed, Aug 17, 2016 at 03:44:48AM +, Nick B via Digitalmars-d wrote: On Monday, 15 August 2016 at 00:42:16 UTC, H. S. Teoh wrote: [...] > Thanks to operator overloading and alias this, we can > probably do a pretty good job implementing unums as a > library so that people can try it out. It may be easier to link to the reference C implementation first. Easier, certainly. But I think D may offer some advantages over a purely C implementation. It's worth exploring, at any rate. For anyone interested, John Gustafson has posted recently a Powerpoint presentation (dated 2 June 2016), which details the failures (both technical and dollar wise) of Floating Point calculations. At the end of the presentation, he details the state of the current implementations (eg Lawrence Livermore National Lab, and others etc), and the proposed implementations in hardware! http://www.johngustafson.net/presentations/UnumArithmetic-ICRARseminar.pptx enjoy. Nick
Re: combine dlang/tools into a single (or a few) binaries
On Saturday, 24 September 2016 at 04:54:51 UTC, rikki cattermole wrote: I'd suggest dlangtools instead. exactly the thing virtually nobody will type even with autocompletion.
Re: Unum II announcement
On Wednesday, 17 August 2016 at 11:34:15 UTC, Seb wrote: If you want Andrei or Walter's opinion on whether they could in principle imagine Unum as part of Phobos or even the language, you should ping them directly via mail. Agreed.
Re: combine dlang/tools into a single (or a few) binaries
On 24/09/2016 9:47 AM, Timothee Cour via Digitalmars-d wrote: instead of having multiple binaries polluting global namespace what about combining them into: dtools --catdoc dtools --changed etc with maybe exception of a few such as rdmd advantages: less pollution of global namespace, smaller overall size (binaries duplicate code), more opportunities for refactoring I'd suggest dlangtools instead. After all, dtools sounds like something that could be used by other projects.
Re: How to link *.a file on Windows?
On Friday, 23 September 2016 at 06:27:20 UTC, Brian wrote: how to static link libmemcached.lib? Just pass the filename to the compiler as if it's a ".d" source and put the path to the sources root with -I dmd app.d libmemcached.lib -Ipath/to/memcached/interface/
Re: What's up with the assert enhancements proposed years ago?
On 09/23/2016 11:47 PM, Nick Sabalausky wrote: On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote: On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d wrote: So...umm...yea...whatever happened to that beefed-up "assert" feature? [...] Ugh, so, "It was rejected for being library instead of assert, then it was rejected for being assert instead of library". /facepalm Guess I'll just have to try getting used to awful Java-isms like x.notEqual(y) :( And then that leads too, to the question of whether such third-party asserts are a good idea for the doc unittests I like so much... :/
Re: What's up with the assert enhancements proposed years ago?
On 09/23/2016 07:57 PM, Jonathan M Davis via Digitalmars-d wrote: On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d wrote: So...umm...yea...whatever happened to that beefed-up "assert" feature? [...] Ugh, so, "It was rejected for being library instead of assert, then it was rejected for being assert instead of library". /facepalm Guess I'll just have to try getting used to awful Java-isms like x.notEqual(y) :(
Interesting talk about language design and evolution
A somewhat lengthy but very interesting talk about the tradeoffs for language design and evolution. [CppCon 2016: Bjarne Stroustrup "The Evolution of C++ Past, Present and Future"](https://www.youtube.com/watch?v=_wzc7a3McOs) In particular the part about direction https://youtu.be/_wzc7a3McOs?t=51m29s, and the section about tradeoffs for new features https://youtu.be/_wzc7a3McOs?t=30m16s.
Re: Documentation unittests are seriously awesome
On 09/23/2016 04:42 PM, Nick Sabalausky wrote:
Just had to say it. Been using it a lot this week.
Referring to this stuff:
/// Does foo stuff
void foo()
{}
///
unittest
{
// Tests and docs in one, 2-for-1 win!
}
And all just built-in. Freaking sweet.
We owe this to Andrej Mitrovic IIRC! -- Andrei
Re: What's up with the assert enhancements proposed years ago?
On Friday, September 23, 2016 16:57:49 Nick Sabalausky via Digitalmars-d wrote: > Some ages ago, a whole suite of "assertPred" functions were written > (giving better diagnostic info, like showing "expected vs actual"), were > totally awesome, were submitted to phobos...and were rejected because it > was deemed both easy enough and preferable to get these features by > modifying DMD to add behind-the-scenes AST magic to "assert". > > So...umm...yea...whatever happened to that beefed-up "assert" feature? It was rejected: https://issues.dlang.org/show_bug.cgi?id=5547 Basically, the review that involved assertPred determined that it would be better to hav assert do it, but when someone tried to put in in the compiler, Walter rejected it, saying that it should be a library solution. There are also some potentially issues having assertions print out additional information in the case where the assertion is not in a unit test and there was concern over that. The big problem with assertPred though is that while it's really nice, it's also really expensive. All of those template instantions really added up. So, I don't know if it's ultimately a good idea or not, but I'd fully expect some of the unit testing libraries to have something similar, even if it's not anywhere near as fancy. - Jonathan M Davis
Re: Argumnentation against external function operator overloading is unconvincing
On 23.09.2016 12:44, Stefan Koch wrote: On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote: FQN disables UFCS. Nothing specific to operators here. There is no reason why there should be any difference between a + b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should work too. Currently this is tricky to implement in the compiler. This can easily be implemented in the parser and in object.d without even changing semantic. This is not the best implementation strategy, but it demonstrates that implementation can be simple. I'm curious to know what strategy you have in mind, and why it would be tricky. BTW: One case for why built-in types should have member call syntax for operators are all the places in e.g. Phobos where code special-cases built-in types in order to be able to use opCmp directly for three-way comparison on user-defined types. And it widens the scope for name-conflicts immensely! ... Operator overloading makes sense for a small minority of types and D has plenty of mechanisms to deal with name conflicts: overload sets, template constraints, private aliases, FQNs. I do not see a case where UFCS overloaded operators are worth the trouble they introduce. IMHO it's a trivial surface language feature allowing convenient syntax for a restricted set of user types. The current limitations are slightly confusing (because a.opBinary!"+"(b) is somehow not the same as a.opBinary!"+"(b)), and also annoying when you run into them. This is not the first time this is discussed.
Re: What's up with the assert enhancements proposed years ago?
On Friday, 23 September 2016 at 20:57:49 UTC, Nick Sabalausky wrote: Some ages ago, a whole suite of "assertPred" functions were written (giving better diagnostic info, like showing "expected vs actual"), were totally awesome, were submitted to phobos...and were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". So...umm...yea...whatever happened to that beefed-up "assert" feature? http://wiki.dlang.org/DIP83 (needs polishing and submission to the new dip process)
Re: Documentation unittests are seriously awesome
On Fri, Sep 23, 2016 at 04:42:26PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
> Just had to say it. Been using it a lot this week.
>
> Referring to this stuff:
>
>
> /// Does foo stuff
> void foo()
> {}
>
> ///
> unittest
> {
> // Tests and docs in one, 2-for-1 win!
> }
>
>
> And all just built-in. Freaking sweet.
+1, yep, I love it too. This is one of D's underrated killer features.
T
--
Life is complex. It consists of real and imaginary parts. -- YHL
combine dlang/tools into a single (or a few) binaries
instead of having multiple binaries polluting global namespace what about combining them into: dtools --catdoc dtools --changed etc with maybe exception of a few such as rdmd advantages: less pollution of global namespace, smaller overall size (binaries duplicate code), more opportunities for refactoring
What's up with the assert enhancements proposed years ago?
Some ages ago, a whole suite of "assertPred" functions were written (giving better diagnostic info, like showing "expected vs actual"), were totally awesome, were submitted to phobos...and were rejected because it was deemed both easy enough and preferable to get these features by modifying DMD to add behind-the-scenes AST magic to "assert". So...umm...yea...whatever happened to that beefed-up "assert" feature?
Documentation unittests are seriously awesome
Just had to say it. Been using it a lot this week.
Referring to this stuff:
/// Does foo stuff
void foo()
{}
///
unittest
{
// Tests and docs in one, 2-for-1 win!
}
And all just built-in. Freaking sweet.
Re: topN using a heap
On Friday, 23 September 2016 at 16:09:18 UTC, Andrei Alexandrescu wrote: BTW, as I commented in https://issues.dlang.org/show_bug.cgi?id=16517, using the new topN implementation instead of sort to compute the median over google's 1-grams is over 11x faster using dmd. That's a very nice result. Both the absolute numbers and that all three sets achieve similar performance, as they different distribution characteristics. --Jon
Re: grpc
On Monday, 30 November 2015 at 14:55:53 UTC, yawniek wrote: would anyone be interested in doing the work for adding D / vibe.d to https://github.com/grpc/grpc ? we currently lack the manpower but would be able to sponsor it (or parts, depending on the effort needed). grpc is probably going to be the dominant rpc system for building a microsrvices architecture. even though i prefer msgpack-rpc i think it would be very valuable in terms of connecting to e.g. GO services. +1
Re: Proof of concept - library AA
On 09/23/2016 03:39 AM, Martin Nowak wrote: On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote: Would be interesting to get some opinions on this. https://github.com/D-Programming-Language/druntime/pull/1282 Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary. - built-in AA is too magic to be replaced by library AA - provide a general purpose library AA with enough benefits for people to live with incompatibilities - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code - make array and AA literals usable with UDTs - slowly deprecated magic behavior of the built-in AA - switch built-in AA to library AA Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff. Seems a good plan to me. I predict the difficult part will be to do that slow deprecation thing; there are quite a few subtleties. But I'm sure we'll overcome them. Thanks! -- Andrei
Re: topN using a heap
On 09/23/2016 11:40 AM, Stefan Koch wrote: On Friday, 23 September 2016 at 15:30:20 UTC, Andrei Alexandrescu wrote: Work is blocked by https://issues.dlang.org/show_bug.cgi?id=16528, which is quite a head-scratcher. Any ideas for a workaround? Thanks! -- Andrei annotate the templates. Nagonna work for generic functions -- Andrei
Re: Proof of concept - library AA
On Fri, Sep 23, 2016 at 06:33:52PM +, Martin Nowak via Digitalmars-d wrote: > On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote: > > On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote: > > Is there any benefit to adding new operator overloading to handle > > this case, like a opValueAssign instead of opIndexAssign ? > > Maybe, making the two implementations behave identical can be done > from both sides, i.e. we'll definitely make literals work for UDTs at > some point, and given how widespread aa[key1][key2]++ is used we might > want to come up with a UDT solution as well, but we can discuss this > as a detail when we're at it. FYI, this is related to this issue: https://issues.dlang.org/show_bug.cgi?id=7753 T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Re: Proof of concept - library AA
On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote: On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote: Is there any benefit to adding new operator overloading to handle this case, like a opValueAssign instead of opIndexAssign ? Maybe, making the two implementations behave identical can be done from both sides, i.e. we'll definitely make literals work for UDTs at some point, and given how widespread aa[key1][key2]++ is used we might want to come up with a UDT solution as well, but we can discuss this as a detail when we're at it. One nice property of the plan is that it's already broken down into digestible changes, might get stuck or fail at any point, but still provides value from the first step on.
Codegen error with -O -cov
https://issues.dlang.org/show_bug.cgi?id=16530 Workaround: use "ref" for the iteration variable. -- Andrei
Re: topN using a heap
On 09/23/2016 11:40 AM, Stefan Koch wrote: On Friday, 23 September 2016 at 15:30:20 UTC, Andrei Alexandrescu wrote: Work is blocked by https://issues.dlang.org/show_bug.cgi?id=16528, which is quite a head-scratcher. Any ideas for a workaround? Thanks! -- Andrei annotate the templates. I don't want to lose the deduction. I used another workaround (enumerate the potential unsafe operations under an if (false) and then forward to a @trusted function) in https://github.com/dlang/phobos/pull/4815. Reviews are welcome! BTW, as I commented in https://issues.dlang.org/show_bug.cgi?id=16517, using the new topN implementation instead of sort to compute the median over google's 1-grams is over 11x faster using dmd. Andrei
Re: topN using a heap
On Friday, 23 September 2016 at 15:30:20 UTC, Andrei Alexandrescu wrote: Work is blocked by https://issues.dlang.org/show_bug.cgi?id=16528, which is quite a head-scratcher. Any ideas for a workaround? Thanks! -- Andrei annotate the templates.
Re: topN using a heap
Work is blocked by https://issues.dlang.org/show_bug.cgi?id=16528, which is quite a head-scratcher. Any ideas for a workaround? Thanks! -- Andrei
Re: Proof of concept - library AA
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote: Bringing up this topic again b/c there was still almost no feedback on the actual plan. Is there any benefit to adding new operator overloading to handle this case, like a opValueAssign instead of opIndexAssign ?
Re: we push flatbuffers for dlang support, no one to help?
On Friday, 23 September 2016 at 11:08:51 UTC, Brian wrote: But the community is so cold? You have mentioned your flatbuffer library once. In that post, you did not mention what it's about or why we might be interested in it. Now, four months later, you come here to berate us for not jumping to help you. Your organization apparently has a few other libraries that may be of note. But if you don't tell us about them, we won't know they exist. It reminds me of part of the Hitchhikers Guide: https://www.youtube.com/watch?v=HNmIQX_ImgM And also this Jeff Atwood post: https://blog.codinghorror.com/but-you-did-not-persuade-me/
Re: we push flatbuffers for dlang support, no one to help?
On 24/09/2016 2:14 AM, CRAIG DILLABAUGH wrote: On Friday, 23 September 2016 at 11:08:51 UTC, Brian wrote: the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold? This seems to suggest it is the D community that is holding this up, but looking at your GitHub page you have a significant input from (prominent) members of the D community. Isn't your issue with Google? It isn't Google, its the committers themselves are holding it up. Someone(s) hasn't signed the CLA.
Re: we push flatbuffers for dlang support, no one to help?
On Friday, 23 September 2016 at 11:08:51 UTC, Brian wrote: the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold? This seems to suggest it is the D community that is holding this up, but looking at your GitHub page you have a significant input from (prominent) members of the D community. Isn't your issue with Google?
Re: Argumnentation against external function operator overloading is unconvincing
On Friday, September 23, 2016 13:47:06 Sai via Digitalmars-d wrote: > > The greatest offender I've found is how in phobos, arrays do > > not behave as ranges without importing the module defining > > their range operations. > > Could you please tell me what module is it? is it std.array? It was, but they were moved to std.range.primitives some time in the last year or two. They're still publicly imported in std.array though, so importing std.array will work. - Jonathan M Davis
Re: Argumnentation against external function operator overloading is unconvincing
The greatest offender I've found is how in phobos, arrays do not behave as ranges without importing the module defining their range operations. Could you please tell me what module is it? is it std.array?
Re: [OT] Re: Why I am switching to Go
On Friday, 23 September 2016 at 01:52:51 UTC, Nick Sabalausky wrote: They've now renamed Syphilis, et al. after Subaru's highest-end Impreza? *shakes head*. Who wants to bet *that* little bit of PC rubble-bouncing was spearheaded by someone with a vested interest in the Viper or Corvette or something? Fine, ok, so who wants to put together the PR to update Phobos's package name accordingly? Any takers? I wonder will programmers be called `digitally oriented persons` one day? And `laptop` sounds too patriarchic for my liking. Let's rename it. How about `mobtop` (mobile desktop)?
Re: [OT] Punctuation of "Params:" and "Returns:"
On 9/23/16 2:17 AM, Mike Parker wrote: On a related note, I recommend anyone who frequently writes (no matter the context -- software docs included) to read Steven Pinker's 'The Sense of Style' [1]. It's practical advice for modern writing that, IMO, does more to destroy Strunk & White (in a respectful manner) than improve upon it. Basically, he dispenses with dogma in favor of practicality. [1] http://stevenpinker.com/publications/sense-style-thinking-persons-guide-writing-21st-century Thanks for the book reco, looks great. -- Andrei
Re: [OT] Punctuation of "Params:" and "Returns:"
On Thursday, 22 September 2016 at 18:26:15 UTC, Andrei Alexandrescu wrote: Parameters: r | The range subject to partitioning. Returns: Something awesome. This is incorrect because one is not supposed to punctuate sentence fragments as full sentences. Next attempt: I also prefer that version. And I think it makes sense even linguistically. Sentences in english could be formalized as: [when/where/why/...]. But sometimes, only fragments of sentences are used, when a fragment is already implied. For instance, for the imperative form, we may write Alice said to Bob: "Do this!". "Do this!" is a perfectly valid english sentence, and the subject is implied: Bob (and not Alice). Expanded, it would give: Alice wants Bob to do this. Or: Alice wants "Bob does this". So, for comments, it is also ok to do the same. i.e. /** * Get a coefficient from the 2D matrix. (subject implied: function getCoef) * * Parameters: * r | Row index. (subject implied: parameter r) * c | Column index. (subject implied: parameter c) * * Returns: * Coefficient fetched at the specified row and column. (subject implied: Return value) */ float getCoef(int r, int c)
Re: we push flatbuffers for dlang support, no one to help?
On Friday, 23 September 2016 at 11:15:32 UTC, rikki cattermole wrote: I pushed a lot of code and tests to your PR, I don't really know whats missing now. imo its usable already but they don't merge it "Need a CLA for one or more commit authors" Also "Still see no documentation, for example".
Re: we push flatbuffers for dlang support, no one to help?
On 23/09/2016 11:12 PM, WebFreak001 wrote: On Friday, 23 September 2016 at 11:08:51 UTC, Brian wrote: the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold? I pushed a lot of code and tests to your PR, I don't really know whats missing now. imo its usable already but they don't merge it "Need a CLA for one or more commit authors"
Re: we push flatbuffers for dlang support, no one to help?
On Friday, 23 September 2016 at 11:08:51 UTC, Brian wrote: the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold? I pushed a lot of code and tests to your PR, I don't really know whats missing now. imo its usable already but they don't merge it
Re: we push flatbuffers for dlang support, no one to help?
On 23/09/2016 11:08 PM, Brian wrote: the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold? I'm not quite sure I understand. What is your connection to the PR exactly? E.g. author/contributor or user of the repository.
we push flatbuffers for dlang support, no one to help?
the pull request: https://github.com/google/flatbuffers/pull/3856 We are putao's huntstudio! We help D language to develop some component support. but, not have yours support??? Long before they have been submitted, but they have not been merged into the branch, flatbuffers is a part of the community, you have a little sense to participation? This community is only publish announcement? My team spent a lot of time to support the development of the D language. But the community is so cold?
Re: Argumnentation against external function operator overloading is unconvincing
On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote: FQN disables UFCS. Nothing specific to operators here. There is no reason why there should be any difference between a + b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should work too. Currently this is tricky to implement in the compiler. And it widens the scope for name-conflicts immensely! I do not see a case where UFCS overloaded operators are worth the trouble they introduce.
Re: [OT] Punctuation of "Params:" and "Returns:"
On Thursday, 22 September 2016 at 18:26:15 UTC, Andrei Alexandrescu wrote: We need to zero in on one good style and use it throughout. Why? Shouldn't the main focus be intelligibility rather than being grammatically correct? I really don't think there should be a hard and fast rule for something this trivial when there are a lot of function docs that still don't have these sections in them.
Re: [OT] Music to Program Compilers To
There are a lot metal fans in here. :) When I code, I listen most of time psychedelic 70's stuff: - Pink Floyd - Led Zeppelin - Lynyrd Skynyrd - Queen - ACDC - Black Sabbath - Rammstein - Robert Wyatt - Renaud Most of the time, I prefer early stuff... When band members don't die chocking in their own vomit or in an airplane crash, they tend to release uninspired music as they grow older. So more early stuff (radio Moscow): https://www.youtube.com/watch?v=LSOqHrYXWSY
Re: Argumnentation against external function operator overloading is unconvincing
On 22.09.2016 10:44, Jonathan M Davis via Digitalmars-d wrote: On Thursday, September 22, 2016 00:14:52 H. S. Teoh via Digitalmars-d wrote: Normally this isn't a problem (D's module system will trigger an overload conflict and require explicit FQN to unambiguously select the right overload), but FQN's are not an option when the call is made from generic code. And in the case of operator overloads, FQN makes no sense at all, since it wouldn't be using the operator anymore. - Jonathan M Davis FQN disables UFCS. Nothing specific to operators here. There is no reason why there should be any difference between a + b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should work too.
Re: Proof of concept - library AA
On Friday, 23 September 2016 at 07:56:02 UTC, Daniel Kozak wrote: What is wrong with built-in AAs? And what advantages comes with library AAs? http://forum.dlang.org/post/uybkxmjlpswufhiwc...@forum.dlang.org
Re: Proof of concept - library AA
Dne 23.9.2016 v 09:39 Martin Nowak via Digitalmars-d napsal(a): On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote: Would be interesting to get some opinions on this. https://github.com/D-Programming-Language/druntime/pull/1282 Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary. - built-in AA is too magic to be replaced by library AA - provide a general purpose library AA with enough benefits for people to live with incompatibilities - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code - make array and AA literals usable with UDTs - slowly deprecated magic behavior of the built-in AA - switch built-in AA to library AA Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff. What is wrong with built-in AAs? And what advantages comes with library AAs?
Re: Proof of concept - library AA
On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote: On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote: Would be interesting to get some opinions on this. https://github.com/D-Programming-Language/druntime/pull/1282 Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary. - built-in AA is too magic to be replaced by library AA - provide a general purpose library AA with enough benefits for people to live with incompatibilities - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code - make array and AA literals usable with UDTs - slowly deprecated magic behavior of the built-in AA - switch built-in AA to library AA Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff. LGTM
Re: Proof of concept - library AA
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote: Would be interesting to get some opinions on this. https://github.com/D-Programming-Language/druntime/pull/1282 Bringing up this topic again b/c there was still almost no feedback on the actual plan. Here is a summary. - built-in AA is too magic to be replaced by library AA - provide a general purpose library AA with enough benefits for people to live with incompatibilities - add a cheap toBuiltinAA adapter for compatibility of the library AA with existing code - make array and AA literals usable with UDTs - slowly deprecated magic behavior of the built-in AA - switch built-in AA to library AA Also we should plan for a std.container.aa to deal w/ all the fancy generic/specialized stuff.
Re: [OT] Punctuation of "Params:" and "Returns:"
On 2016-09-22 20:26, Andrei Alexandrescu wrote: Parameters: r | the range subject to partitioning Returns: something awesome So now we don't use a leading capital and punctuation. The challenge here is when the parameter description takes more than one sentence: I use this style. Parameters: r | the range subject to partitioning. For whatever reason there's a need for a second sentence, so we need to put a period and mess it all up. Returns: something awesome. Sadly, it takes one extra sentence too, making the "something awesome" text awkward. We need to zero in on one good style and use it throughout. Thoughts? For the parameters I would skip the trailing period. I view the parameters as a list and I've learned that the items in a lists (bullet point lists) should not end with a period. I might be completely wrong and it might not apply to English, but that's what I do. Keep in mind as well that all this might also depend on how Ddoc renders the documentation. For example, if Ddoc renders the returns section like this: Returns: some useful value Then it make senses to skip the leading capitalization. But if Ddoc renders the section like this: Return Value: some useful value Then it might look awkward to not use leading capitalization. Same thing with the parameters. It all depends on if the section/parameter is rendered in a way that it makes sense/make it look like the section/parameter is part of the sentence. -- /Jacob Carlborg
