Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 14:45:19 UTC, Adam D. Ruppe wrote: On Thursday, 29 January 2015 at 11:17:32 UTC, Mike wrote: Is the concept of a *window* even that platform agnostic? Generally, I think it is a mistake to reject something that is good for a great many users just because it isn't available everywhere. If it isn't right for your target, just don't use it. I agree 100%. Moreover C++ std lib have features not present on all targets, e.g. threads. Piotrek
Re: DerelictSASS
Major update for DerelictSASS and Sassed due to C API change in libsass. DerelictSASS - v2.0.0 https://github.com/Lodin/DerelictSASS There are complete interface change: as I know, previous libsass C API does not work anymore, and new API was written. Sassed - v0.2.0 https://github.com/Lodin/sassed It is updated to new DerelictSASS version and has some new features such as sass compile error and success handlers. Also segfault bug was fixed.
From C#7 and Haskell
Design Notes for C#7: https://github.com/dotnet/roslyn/issues/98 Perhaps they will enhance C# switch (plus an optional special method) to support a form of pattern matching. I'd like something related in D, someday. - - - - - - - Haskell in the large (PDF): http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf It's perhaps the first time I see Haskell used for a large program and system. New things: - Data mining: In-language relational algebra data structures and API. - Memoization: In-language data flow graph library with memoization support. Native relational algebra data type. - An awful lot of data mining and analysis is best done with relational algebra. - Not just in the database. Bye, bearophile
Re: accept @pure @nothrow @return attributes
On 28/01/2015 22:44, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Could it be that new languages define grammars that are more robust than the one used by C? Like Go? We're not going to significantly change the structural syntax of D, so it doesn't seem that your argument is particularly relevant here.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 16:13:59 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used
everywhere ? By the way, the denomination makes sense too :
function attibutes are either built-in or user defined
attributes. But const can be a qualifier or a
function/method attribute that is two very different
things...maybe not beeing able to use const as a function
attribute but @const would make more sense ?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in
the other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of
them for the sake of consistency. The problem with this idea
is that you've now introduced inconsistency somewhere else.
Every keyword that you put an '@' symbol in front of, will be
used somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of
these types of inconsistencies. In addition, you've made the
rule of when to use the '@' symbol more complex. Before it
was, Use '@' if it is not a keyword. Now it's, Use '@' if
it is not a keyword except when it's a function attribute.
This definition will likely be made worse since people will
want to solve the newly introduced inconsistencies. So the
new definition will become, Use '@' if it is a keyword
except if it's a function attribute or a class specifier.
By the time you solve every inconsistency you'll have made
every usage of every keyword use the '@' symbol. Then the
rule will be Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword
it and modify it but I agree that people will want an
explanation for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to
distinguish beetween qualifiers and attributes. But I
understand legacy code is an issue and I agree that the FAQ
should just state the facts.
This doesn't really have to do with Legacy code. You can
always support both ways for a time and deprecate the old way.
It appears my answer did not address your idea well enough.
I'll have to put together a better explanation. In the mean
time, could you help me by giving me the gritty details of your
idea. I know others will also want an explanation for this so
I'd like to include one in the FAQ so as to prevent us from
explaining the same thing over and over. You idea was to put
'@' on words if they are attributes and to omit them on
qualifiers. Could you list what words are qualifiers and what
words are attributes? I don't think this idea would work but
hey, maybe you'll prove me wrong, I'll admit I haven't gone
through the details of what problems this idea would create.
Sorry this may be my fault. I think there were only 4 qualifier
in D : const, immutable, share and inout (I am not aware of this
new scope thing). pure is a function attribute and a keyword,
this is inconsistant with other built-in attributes with @ in
front of them like @property or @nogc. I think (and my opinion
doesn't worth much as I am not experienced as a programmer and I
didnt used D very much) that it would be more consistant if we
hadn't this keyword and be forced to use @pure instead. (const
can be a method annotation/attribute too, so should be @const
keeping const as a variable/parameter qualifier).
Re: What is RTInfo?
On Thursday, 29 January 2015 at 08:47:18 UTC, Mike wrote: It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. It can actually return anything: RTInfo is a template that is automatically instantiated for each user-defined struct or class in a program. https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L682 It isn't actually doing anything yet in the lib, but it could if you wanted to modify druntime. IT can do anything - custom, user extensions to TypeInfo, building trees of types, or making maps of things for the GC (which is why it is there, just nobody has actually used it yet). It is one of the cool hidden gems there that is unutilized so far.
Pull Request Challenge for D
Hi all 1) found this and somehow like that idea. maybe it's also a way forward for us ;) https://huntingbears.nl/2015/01/11/cpan-pull-request-challenge-for-january-datetimeformatepoch/ 2) as D upload/download statistics are always in the forums, I also like this page and hope it can be inspiring ;) http://stats.cpantesters.org/uploads.html regards anton oks
Re: something weird with strerror_r
On Thursday, 29 January 2015 at 14:40:32 UTC, CodeSun wrote: writeln(cast(string)buf); Casting to string is often a mistake, here it might be the problem because you didn't check for the zero terminator, so the writeln prints all the garbage at the end of the buffer too. I'd try something like char[128] buf = 0; // initialize it all to zeroes // fill it here with the function printf(%s\n, buf.ptr); // display with printf which respects 0 and see what happens, if that works, the problem is just converting from C string back to D string, which you can do with to!string(buf.ptr) or another slicing method which is more efficient if you search for the zero yourself.
Re: What is RTInfo?
On 1/29/15 3:47 AM, Mike wrote: object.d [1] says it's infomation for the precise GC (which I thought wasn't implemented yet). It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. So, what is RTInfo and what is its purpose. And how is it different from TypeInfo? For every TypeInfo generated by the compiler, it also instantiates the RTInfo(T) template [1] and puts the result into m_rtInfo. This allows anyone to generate anything they want at compile time and put it into the TypeInfo system. Could be Precise GC stuff, could be reflection stuff, anything you want. At the moment it's just a toy for tinkerers to try nifty things with :) There has been discussion as to how we can make the system extensible, so you don't have to build a new runtime to add things to TypeInfo. But nothing concrete so far has been added. It's just a hook from the compiler. -Steve [1] https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L682
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote: It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation? Anyone else for or against this? If no one protests I can create it, along with the FAQ from matovich and including Walters extra explanation about increasing redundancy.
Re: How can I help with pull requests if I don't have the authority to merge?
On 1/29/15 5:42 AM, Atila Neves wrote: After this thread: http://forum.dlang.org/thread/hapxxhusoniimfxie...@forum.dlang.org I had some time today and headed over to Github to see if I could help out. But I'm not sure what I can do if I don't have the power to approve PRs. I'm not asking for that power, I haven't earned it yet. I'm just asking what it is I can do to help, especially on PRs that already have comments from a bunch of people. Should I add comments to the ones that don't? Work on my own PRs instead? Atila Yes to both. A review carries a lot of weight. New work is of course great but takes larger chunks of time. -- Andrei
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 14:05:25 UTC, Chris wrote: Yeah, I was wondering, if you have to import std.json and use it as a basis for painlessjson, is it really so big an improvement? Especially since std.json might be replaced (sooner or later). I'd prefer an easy to use implementation that replaces std.json completely. Painlessjson in many ways abstracts away the std.json implementation, so using it you should rarely/never have to use std.json directly. It basically abstracts away most of the complexity and you should only ever have to use toJSON and fromJSON. This works with built-in types (double/int/string etc.) and also with ranges and associative arrays. On top of that Painlessjson also makes it easy to convert your own types/struct/classes to and from JSON by (de)serializing them automatically (as far as possible). If a better simpler std.json gets developed then we can rebase painlessjson on that and it might become a thinner wrapper, but I would expect the (de)serialization still to be useful in many cases.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 1/29/15 5:14 AM, Mathias LANG wrote: On Wednesday, 28 January 2015 at 19:06:23 UTC, Andrei Alexandrescu wrote: On 1/28/15 11:04 AM, Brad Roberts via Digitalmars-d wrote: Sorry, typed those by hand rather than cut/paste. Pluralize each: http://downloads.dlang.org/pre-releases/ http://downloads.dlang.org/releases/ BTW how do I distinguish automated (e.g. Travis-CI) downloads from regular downloads? Thanks! -- Andrei Travis set the User agent this way: $ CURL_USER_AGENT=Travis-CI $(curl --version | head -n 1) Thanks! -- Andrei
[Issue 14061] Refused array concat at compile-time
https://issues.dlang.org/show_bug.cgi?id=14061 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4356 --
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:43:37 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence. JM Davis Ok ! I'm not sure I understand your question. Why don't we make all the function attributes attributes? Is this what you mean? Why don't we require an '@' symbol before all function attributes?
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. And it is so bad when the codebase grows that people are willing to switch to Node.js (!)
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 13:58:52 UTC, Jacob Carlborg
wrote:
A good language design that doesn't require the ; statement
terminator would recognize void func() as a valid statement
and implicit add ;. Scan the line, if a valid language
construct has been seen at the end of the line, insert a ;, if
not continue to the next line. That works in many languages.
Tells me what this function returns in javascript :
function foo()
{
return
{
foo: bar,
}
}
Yes, you guessed right, it returns undefined. Ho you didn't ?
What a surprise !
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 17:17:44 UTC, deadalnix wrote: On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. And it is so bad when the codebase grows that people are willing to switch to Node.js (!) That is so yesterday, they are now either on Go or Clojure.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On 29/01/2015 15:54, Jonathan Marler wrote:
Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these types of
inconsistencies. In addition, you've made the rule of when to use the
'@' symbol more complex. Before it was, Use '@' if it is not a
keyword. Now it's, Use '@' if it is not a keyword except when it's a
function attribute. This definition will likely be made worse since
people will want to solve the newly introduced inconsistencies. So the
new definition will become, Use '@' if it is a keyword except if it's a
function attribute or a class specifier. By the time you solve every
inconsistency you'll have made every usage of every keyword use the '@'
symbol. Then the rule will be Always use the '@' symbol.
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is variables
that don't use @attribute syntax. This is not something I invented, it
follows on from existing uses of @attributes and __keywords already
supported by dmd.
Re: Window creation, for phobos?
I'm chipping away at a colour module, although I've been distracted with work the last little bit. I'm not convinced that D needs a custom GUI library though. That's a behemoth effort. I tend to think a quality and well-maintained Qt binding/wrapping would be a much more useful tool for us to have. It's kind of a de-facto standard for portable gui these days. It will also retain interoperability with other existing C/C++ code (of which there is much), etc. It will also get us mobile UI as a freebie, which is a market we really want to get amongst. You can't really overlook the man years in Qt, and the maturity of the ecosystem. On 28 January 2015 at 08:04, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: I have dream! A dream, dream dream. A dream to see GUI's easy to use in D! I must admit it will be hard, but it's time. Prime time I mean! Now enough gabble. I'm proposing to get Devisualization.Window PR'd into phobos. This cannot happen right now. It's blocked on many fronts. 1) Objective-C bridge. The most obvious one for OSX 2) An image definition depends on color 3) OpenGL loading mechanism such as Derelict-GL3 4) X11 bindings for posix (easy not an issue) 5) More WinAPI bindings (easy not an issue) 6) Cocoa bindings (easy not an issue, just dependent on the bridge) 7) A color definition So this idea will take a long time to happen, and that's ok. First off, Derelict-Util/Derelict-GL3 is a biggy here. Its old code, lets admit it. Its also a standard for loading shared library functions. So Mike Parker, would you be willing for this to be PR'd? And if so, are we ok with this? Manu Evans has said he is working on a color module, any update on that? Jacob Carlborg, how far off is the objective-c bridge? Has any definitions to e.g. Cocoa been started either? Once we have a color definition then it'll be time to start work on an image definition/implementation. There is a few already present, ae, dlib and Devisualization.Image exist. The color implementation will change, but most of the code should not for each. Anyone willing to start working on something? The benefits of this will greatly outweigh the work that this will take to do and maintain. Just having a standard window + context interface will greatly make GUI toolkits more interchangeable. Not to mention for game development.
Re: Window creation, for phobos?
On Wednesday, 28 January 2015 at 12:02:25 UTC, Dicebot wrote: GUI does not belong to Phobos. That's the only reason I use Java instead of D. If GUI is not in phobos, it has no guaranteed support. Of course this is because I only create GUI desktop application. Apparently this is only my issue, all others seems to be ok with no GUI in phobos.
Re: Window creation, for phobos?
On 29/01/2015 9:09 p.m., user wrote: On Wednesday, 28 January 2015 at 12:02:25 UTC, Dicebot wrote: GUI does not belong to Phobos. That's the only reason I use Java instead of D. If GUI is not in phobos, it has no guaranteed support. Of course this is because I only create GUI desktop application. Apparently this is only my issue, all others seems to be ok with no GUI in phobos. Right now I won't be suggesting any form of GUI toolkit. So even if this got into phobos it wouldn't help most people. It'll take at least a couple of years even if we Devisualization.Window is agreed to be the standard window/context creation library in the D community. Getting a GUI toolkit into phobos isn't in the near future. So I won't be pretending it is. I do hope though in a few years time, we can work with GUI's semi decently cross platform.
What is RTInfo?
object.d [1] says it's infomation for the precise GC (which I thought wasn't implemented yet). It just seems to return a void*. But, searching the source code, it doesn't seem to be set by anything anywhere. So, what is RTInfo and what is its purpose. And how is it different from TypeInfo? Thanks, Mike [1] https://github.com/D-Programming-Language/druntime/blob/f0c1e13d8bd547eed517b1ae17f085966bb165c1/src/object.di#L180
Re: Window creation, for phobos?
On 29/01/2015 9:45 p.m., Manu via Digitalmars-d wrote: I'm chipping away at a colour module, although I've been distracted with work the last little bit. I see, anything I can help with? I'm not convinced that D needs a custom GUI library though. That's a behemoth effort. I tend to think a quality and well-maintained Qt binding/wrapping would be a much more useful tool for us to have. It's kind of a de-facto standard for portable gui these days. It will also retain interoperability with other existing C/C++ code (of which there is much), etc. It will also get us mobile UI as a freebie, which is a market we really want to get amongst. You can't really overlook the man years in Qt, and the maturity of the ecosystem. I agree about Qt. It would be definitely nice to get something like that on e.g. dub. I wouldn't call it a freebie for on mobile however. We would still have to manage binaries ext. outside of D land. Okay for argument sake completely hypothetical. Lets say I complete Devisualization.gmaterial. It uses OpenGL to render. Assuming symbols can be loaded via e.g. Derelict-GL3 on an Android device this way. The only thing limiting it is Devisualization.Window with window and context creation. This will be quite easy to do. Especially with my work with Djvm it would be very enjoyable experience. iOS is even easier, its mostly copy paste the OSX implementation and rename. It would be a bit of work. But it wouldn't be much considering. Now this I consider a freebie. Considering we could advertise it was purely D cross platform GUI toolkit with mobile support. I will say this about Google Material Design, its reasonably simple. I'm pretty close to getting the main infrastructure completely done. I was held up on shadows for paper sheets. I have figured out a simple way to do it however. At least to fake them.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote: I take it you also don't care if your IDE lags for 5 seconds every time you type a character? Actually, modern parsers can parse ambiguous grammars in O(N) using memoing. Just because you are reluctant to implement a modern parser does not mean that it cannot be done and wrapped up as a library. I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. D does not even have a published grammar that rejects programs that are not well formed. The problem is not that having a programmer friendly will cause tool writer problems. The problem is in D specification and semantics which are C++ish. What people have requested is not C++ish it is well within a CFG. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines. What is easy for a standards committee is to check that their data structure definitions are implementable in C, C++, Java, C# and SQL. Not being able to repesent those in D will make D less attractive. Besides there is no ambiguity in allowing arbitrary field names since they are preceded by a .. (nobody cares about local variables)
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad wrote: Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use body as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release. In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). This role was rediscovered as product owner in Agile settings. Strong leadership and saying no more often that people would like is a constant among good projects. I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.
[Issue 11736] segfault combining std.parallelism.parallel and std.process.executeShell
https://issues.dlang.org/show_bug.cgi?id=11736 Szymon Gatner szymon.gat...@gmail.com changed: What|Removed |Added CC||szymon.gat...@gmail.com --- Comment #2 from Szymon Gatner szymon.gat...@gmail.com --- Also affected by this but found that replacing std.process.executeShell() with deprecated std.process.system() does not cause crash so I suspect it probably has to do with executeShell() capturing process output? Im on Win7 x64, using DMD 2.066.1 --
Re: Import paths do not work
I would suggest instead of using make, use dub[0] build manager instead. It'll handle grabbing all the files and compiling them correctly. [0] http://code.dlang.org/package-format Or for simple projects such as this one seems to be, just use rdmd. Atila
Re: What is @return?
@property auto info() @safe @nothrow @pure @return const { return this; }
It is mesmerizing... (@ _ @)
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote: In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). You mean like Batman? I don't feel like discussing system development principles with you if you think the dynamic duo is anywhere near following sound software engineering principles. It is not a fun topic to teach (yes, I have done that). This role was rediscovered as product owner in Agile settings. Strong leadership and saying no more often that people would like is a constant among good projects. The only thing that truly matters is that you have a plan and a reasonable process to back it up. Leadership is about facilitating the process. A role is not a person, it is backing a task that to be fulfilled to facilitate the process in a predictable and orderly fashion. I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze. I personally don't think it is reasonable for Walter and Andrei to present D as a tool that is suitable for production. If it is, then they have to fess up to massive critique. Take a look at dlang.org, where does it say experimental language? It used to say beta, which actually should have been alpha... I personally only want D to follow sound engineering principles. I personally don't want syntax changes or feature freeze, since it won't help without a solid process to back it up. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there. I think it is abusive and dishonest to present a language as ready for use when it nowhere near a stable release. I've previously requested that they actually do language design by writing up a spec for where D is heading, so that people can make up their mind and decide to provide implementation power if they like the presented outcome. Without a clear horizon, it makes no sense to participate unless you have it as a hobby. That slows down progress. That is what makes Rust and Go winners and D a stagnation. What I suggest is the best for D is: 1. Feature freeze. 2. Fix semantics/refactor compiler internals. 3. Fix syntax to be mainstream friendly. In that order. I have no hope that it will happen without a major restructuring of the process. I'm totally with ketmar on that front.
Re: Window creation, for phobos?
On Tuesday, 27 January 2015 at 22:05:02 UTC, Rikki Cattermole wrote: I have dream! A dream, dream dream. A dream to see GUI's easy to use in D! I must admit it will be hard, but it's time. Prime time I mean! Now enough gabble. I'm proposing to get Devisualization.Window PR'd into phobos. I would love to see some facilities in D for GUI development, but I'm not sure about window creation. Is the concept of a *window* even that platform agnostic? I thought that was mostly a desktop metaphor. There are a few fundamental packages related to this domain that I think would fit nicely into Phobos, and could potentially plant a few seeds in this community that might spur exponential growth. 1. Color package 2. 2d/3d geometry package 3. Frame buffer package (Does OpenGL/DirectX make this obsolete?) With those in place... 4. Imaging package 5. Vector graphics package 6. SVG package 7. Perhaps some kind of an input package etc... You get the idea: Build a few platform agnostic fundamentals and I think the community will take it from there. And once these are in place, a GUI toolkit isn't far away, and wouldn't need to have dependencies on 3rd party libraries. But all this would be hard work, especially if it's intended to pass the high bar of standard library inclusion. I have an interesting use case such for such libraries. I sometimes build small HMIs (Graphical touch screens) for machines like thermostats, refrigerators, vending machines, etc... The hardware is very resource constrained. The LCDs are typically no greater than RGB666, so the primary frame buffer is RGB565 to save on memory. The API thinly exposes color as RGB, as that's a little more convenient to work with. Almost all graphics is done in software with DMA being the only real hardware support. I've been exploring D, Rust, and Nim for use in this domain. I know this is a niche domain for D, but it seems these facilities, if designed to be efficient with resources, would scale well to, and perform superbly on, more resource abundant platforms. Mike
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak
wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see any
reason why it's a bad thing. It doesn't make the syntax more
complicated, it doesn't maker it harder to parse, I just
don't see why its bad.
Thats not possible:
@safe {
void some func() // now valid
}
safe:
void some func() // now valid
safe {
void some func() // could not be valid
}
safe:
void some func() // could not be valid
So you need more places where keyword needs to be contextual
keyword
And this is a path I am not sure we want to go.
None of those cases would valid. Non-Keyword attributes
without a '@' must be on the right hand side of the function
parameters.
Then I'm afraid the proposal is pointless :-( The goal AIUI is to
make the language more consistent. If we can't use the new syntax
everywhere (and later get rid of the old one), we can't achieve
that.
Re: D Meetup in Berlin
Oops, I forgot to also mention that we now also have a meetup page here: http://www.meetup.com/Berlin-D-Programmers/
Re: Window creation, for phobos?
On 30/01/2015 12:17 a.m., Mike wrote: On Tuesday, 27 January 2015 at 22:05:02 UTC, Rikki Cattermole wrote: I have dream! A dream, dream dream. A dream to see GUI's easy to use in D! I must admit it will be hard, but it's time. Prime time I mean! Now enough gabble. I'm proposing to get Devisualization.Window PR'd into phobos. I would love to see some facilities in D for GUI development, but I'm not sure about window creation. Is the concept of a *window* even that platform agnostic? I thought that was mostly a desktop metaphor. Lets use iOS/Android as an example. On Mobile an app only has one window, so the implementation is defined to be singleton. Except Android can also be used with tv's, so its not really singleton. Things like a window icon or minimize/maximize may not be applicable to certain platforms and that's ok. That's what exceptions / @disable is for. There are a few fundamental packages related to this domain that I think would fit nicely into Phobos, and could potentially plant a few seeds in this community that might spur exponential growth. 1. Color package 2. 2d/3d geometry package 3. Frame buffer package (Does OpenGL/DirectX make this obsolete?) With those in place... 4. Imaging package 5. Vector graphics package 6. SVG package 7. Perhaps some kind of an input package etc... You get the idea: Build a few platform agnostic fundamentals and I think the community will take it from there. And once these are in place, a GUI toolkit isn't far away, and wouldn't need to have dependencies on 3rd party libraries. But all this would be hard work, especially if it's intended to pass the high bar of standard library inclusion. Yup, and now you know how I'm making Devisualization in general. We are 100% on the same page! I have an interesting use case such for such libraries. I sometimes build small HMIs (Graphical touch screens) for machines like thermostats, refrigerators, vending machines, etc... The hardware is very resource constrained. The LCDs are typically no greater than RGB666, so the primary frame buffer is RGB565 to save on memory. The API thinly exposes color as RGB, as that's a little more convenient to work with. Almost all graphics is done in software with DMA being the only real hardware support. I've been exploring D, Rust, and Nim for use in this domain. I know this is a niche domain for D, but it seems these facilities, if designed to be efficient with resources, would scale well to, and perform superbly on, more resource abundant platforms. Awesome! It definitely is pushing anything I am considering, let alone proposing though. No way any of the libraries we will get into phobos will be designed for ultra memory tight.
Re: Problem with coupling shared object symbol visibility with protection
On 1/28/2015 5:19 AM, Benjamin Thaut wrote: On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright wrote: The example had marked the template itself as 'export'. This raises the specter of which binary the template instantiation exists in. The export in this context actually means export all instanciations of this template. And this is needed to avoid using -allinst everywhere. The problem is what happens when the client side instantiates the template, which it must in order to use it.
Re: Problem with coupling shared object symbol visibility with protection
On 1/28/2015 5:27 AM, Benjamin Thaut wrote: Also sorry for the harsh answer, this was a classical double misunderstanding. No problemo.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic wrote: helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on! Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use body as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ?
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence. JM Davis Ok !
Re: shared Variant[string]
On Wednesday, 28 January 2015 at 12:29:09 UTC, Fyodor Ustinov
wrote:
On Wednesday, 28 January 2015 at 11:27:53 UTC, Kagamin wrote:
Associative array doesn't support thread-safe operations,
that's why they don't work on shared instance. You should use
std.concurrency or implement low-level concurrency mechanism.
If associative array does not support share attribute, this
code should not be compiled without any warning or error, I
think:
shared string[string] t;
void main() {
t[t] = bebebe;
}
But will.
string is a shorthand for immutable char - and immutables are
shared by default. No thread can modify them, so default shared
is safe for them.
Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 08:09:16 UTC, user wrote: Apparently this is only my issue, all others seems to be ok with no GUI in phobos. NO... I am not ok with no GUI in phobos. I am with you.
Re: D Meetup in Berlin
Good news everyone! We have a date and location for the 2nd D meetup. The meetup will take place on Friday the 20th of February at 19:30. The new location is the 3rd floor of the Co Op Berlin building (http://co-up.de/). This meeting will involve a presentation and I will post again when the presenter and topic are confirmed.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes?
Check if type is from specific template?
Basically what the title says, how do I check if a type T is an instantiation of a specific template?
Re: Check if type is from specific template?
Tofu Ninja: Basically what the title says, how do I check if a type T is an instantiation of a specific template? If you have an updated Phobos std.traits.isInstanceOf could be what you look for. Bye, bearophile
Re: Problem with coupling shared object symbol visibility with protection
On Thursday, 29 January 2015 at 10:21:25 UTC, Walter Bright wrote:
On 1/28/2015 5:19 AM, Benjamin Thaut wrote:
On Wednesday, 28 January 2015 at 11:01:09 UTC, Walter Bright
wrote:
The example had marked the template itself as 'export'. This
raises the
specter of which binary the template instantiation exists in.
The export in this context actually means export all
instanciations of this
template. And this is needed to avoid using -allinst
everywhere.
The problem is what happens when the client side instantiates
the template, which it must in order to use it.
Well if there already is a statically known instanciation it will
not instanciate it. (I didn't change that behvaior). The question
is what happens when you have something like this:
module a:
struct SomeTemplate(T){}
alias knownInstance = SomeTemplate!int;
module b:
SomeTemplate!int var1; // will use instanciation from a (unless
-allinst)
SomeTemplate!float var2; // will instanciate
alias knownInstance2 = SomeTemplate!uint;
module c:
SomeTemplate!uint var3; // will this use instaction from b? Or
instanciate itself?
I don't know enough about D's template implementation to answer
the question regarding c.var3. Depending on the answer to this
question I can answer what should happen if a export marked
template is instanciated outside of its module. (e.g. by the user)
Please also correct me if any of the above assumptions are
incorrect.
[Issue 14077] Letting compiler determine length for fixed-length arrays in return type
https://issues.dlang.org/show_bug.cgi?id=14077 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Summary|Issue 14070 - Letting |Letting compiler determine |compiler determine length |length for fixed-length |for fixed-length arrays in |arrays in return type |return type | --
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. That explains why new languages make ; optional, or wait... Could it be that the language designers of new languages have realized that using ; for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go? Counter example: Rust. Of course, Rust isn't the epitome of readability. Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On Wednesday, 28 January 2015 at 19:06:23 UTC, Andrei Alexandrescu wrote: On 1/28/15 11:04 AM, Brad Roberts via Digitalmars-d wrote: Sorry, typed those by hand rather than cut/paste. Pluralize each: http://downloads.dlang.org/pre-releases/ http://downloads.dlang.org/releases/ BTW how do I distinguish automated (e.g. Travis-CI) downloads from regular downloads? Thanks! -- Andrei On way could be to measure (unique) visits to http://dlang.org/download.html. Assuming regular downloads are people on the internet getting D manually. For more accurate numbers you might want to measure clicks on download links on dlang.org/download.html. This would need to be done with client side javascript.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:25:05 UTC, Dicebot wrote: On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote: Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. Same for any symbol. Do you have a solution? Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise) I suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system.
Re: something weird with strerror_r
On 1/29/2015 11:40 PM, CodeSun wrote:
Recently, I found something really weird when I use strerror_t function
which is declared inside std.c.string.
The code snippet is listed below:
import std.c.string;
import core.stdc.errno;
void main() {
import std.stdio;
char[128] buf;
strerror_r(errno, buf.ptr, buf.sizeof);
writeln(cast(string)buf);
}
The terminal should print Success with errno=0, but in this example,
the result is
.
I test this snippet both on Archlinux and Ubuntu 14.04.1, and the result
is same. If there is someone can help me?
I wanna know if it is my mistake or it is just a bug.
Thx!
The GNU version of strerror_r is documented as returning
a pointer to a string containing the error message. This may be either
a pointer to a string that the function stores in buf, or a pointer to
some (immutable) static string (in which case buf is unused).
So I think what you may have been seeing in this case is that it was
returning a static string, your buffer remained empty and the writeln
was printing a bunch of 0xFFs. Probably this is a better way to handle it:
void main()
{
import core.stdc.errno : errno;
import std.c.string : strerror_r;
// Static arrays are initialized to T.init. For
// char, T.init is 0xFF, *not* 0. The initializer
// here will fill the array with 0.
char[ 128 ] buf = 0;
auto cstr = strerror_r( errno, buf.ptr, buf.sizeof );
// Slice the C string with fromStringz. Unlike to!string, this
// does not allocate or copy.
import std.string : fromStringz;
writeln( cstr.fromStringz() );
}
Re: DlangUI
On Thursday, 29 January 2015 at 14:13:22 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 14:21:36 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 13:37:34 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 10:57:57 UTC, Vadim Lopatin wrote: BTW, could you try on mac https://github.com/buggins/dlangide.git as well? It's dlangui-based D language IDE I'm currently working on. That works OK. The text is all horrible looking. This is probably due to (lack of) scaling support for high-res screens (retina). Is graphics scaled too? If so, it's due to scaling. Otherwise possible it's due to bad implementation of subpixel antialiasing (aka ClearType). I've submitted fix to disable subpixel antialiasing. An example of what I see (with up-to-date git HEAD) https://www.dropbox.com/s/49n9m0b9uutzaa8/Screenshot%202015-01-29%2014.11.57.png?dl=0 I see no additional blur comparing with other platforms. It's bad font rendering. Trying to improve. P.S: DlangIDE is now able to open DUB based projects, build and run them, edit files. Good sample project is dlangide/workspaces/tetris :)
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 2015-01-28 20:04, Brad Roberts via Digitalmars-d wrote: Sorry, typed those by hand rather than cut/paste. Pluralize each: http://downloads.dlang.org/pre-releases/ http://downloads.dlang.org/releases/ Awesome, thanks. -- /Jacob Carlborg
Re: file(line, col)=file(line:col) to follow convention of clang, gcc, dscanner etc
On 2015-01-28 22:52, Timothee Cour via Digitalmars-d wrote: See also https://github.com/Hackerpilot/Dscanner/issues/224 It breaks tooling that expects the main convention. Yeah, TextMate expects a colon as separator. That DMD uses a comma forced me to write a completely new error handler in TextMate. -- /Jacob Carlborg
Re: Check if type is from specific template?
On Thursday, 29 January 2015 at 12:10:41 UTC, bearophile wrote: Tofu Ninja: Basically what the title says, how do I check if a type T is an instantiation of a specific template? If you have an updated Phobos std.traits.isInstanceOf could be what you look for. Bye, bearophile Yep, exactly what I needed. Incidentally, while trying to see how its used I found that a lot of the links on the std.traits doc page do not work and have no documentation. For instance http://dlang.org/phobos/std_traits.html#isInstanceOf does not actually appear on the page but has a link to it up in the navigation header. Other links on that page that don't work... isAssignable, isBoolean, isIntegral, isFloatingPoint, isNumeric, isScalarType, isBasicType, isUnsigned, isSigned, isSomeChar, isSomeString, isNarrowString, isStaticArray, isDynamicArray, isArray, isAssociativeArray, isBuiltinType, isPointer, isAggregateType, isIterable, isMutable, isInstanceOf, unsigned It seems that all the variable template's docs are not getting generated...
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On Wednesday, 28 January 2015 at 19:06:23 UTC, Andrei Alexandrescu wrote: On 1/28/15 11:04 AM, Brad Roberts via Digitalmars-d wrote: Sorry, typed those by hand rather than cut/paste. Pluralize each: http://downloads.dlang.org/pre-releases/ http://downloads.dlang.org/releases/ BTW how do I distinguish automated (e.g. Travis-CI) downloads from regular downloads? Thanks! -- Andrei Travis set the User agent this way: $ CURL_USER_AGENT=Travis-CI $(curl --version | head -n 1)
[Issue 14075] [REG2.067a] Segfault with ambiguous overloading functions without body
https://issues.dlang.org/show_bug.cgi?id=14075 sinkuup...@gmail.com changed: What|Removed |Added Summary|[REG2.067a] ICE with|[REG2.067a] Segfault with |ambiguous overloading |ambiguous overloading |functions without body |functions without body --
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 13:16:48 UTC, BlackEdder wrote:
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source it
seems to have a different goal though. dson looks like it is an
alternative to std.json. Painlessjson is meant to make it
easier to use json, by automatically (de)serializing
objects/structs and converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of std.json
as a basis for Painlessjson.
I believe we should continue using std.json, and instead push for
taking dson (or its lessons learned) into phobos if it's a better
implementation. The best general solution should be the one that
is available out of the box.
Re: This Week in D, Issue 3
On Monday, 26 January 2015 at 05:15:51 UTC, Adam D. Ruppe wrote: I've been out of town this week and also dealing with trying to remotely find my lost dog (she got away from the sitter... and no luck yet :( ) so I haven't been as active as I often am in the D community, but I still made time to compile another issue! http://arsdnet.net/this-week-in-d/jan-25.html Also available via RSS: http://arsdnet.net/this-week-in-d/twid.rss This week's tip goes into the import statement which many people use but not everyone realizes what all it can do. D.announce seemed a bit less active this week too (my criteria for inclusion there is simply a new thread made since last time, so new posts in an existing thread don't count), but there were a lot of bug and pull request action this week (mostly related to the style tweaks)! Hi Adam, enjoy reading your articles but it was/is kind of difficult to find them. I browse dlang.org frequently but irregularly and Issue 3 popped accidentally into my eye. I could not find any obvious link to Issues 1 and 2 (searching the announce forum does not count as obvious) and had to guess the URLs based on weekly. I would suggest to collect the links to all Issues on the URL: http://arsdnet.net/this-week-in-d What do you think? Regards, ParticlePeter
[Issue 14076] New: Partial type deduction doesn't work with lambdas
https://issues.dlang.org/show_bug.cgi?id=14076 Issue ID: 14076 Summary: Partial type deduction doesn't work with lambdas Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: rejects-valid Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: k.hara...@gmail.com Test case: immutable pure @safe bool function(in bool[])[2] a481_19x = [ s = s[0], s = s[0] ]; immutable pure @safe bool function(in bool[])[$] a481_19y = // doesn't work [ s = s[0], s = s[0] ]; static assert(is(typeof(a481_19x) == typeof(a481_19y))); --
[Issue 14076] Partial type deduction doesn't work with lambdas
https://issues.dlang.org/show_bug.cgi?id=14076 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4355 --
How can I help with pull requests if I don't have the authority to merge?
After this thread: http://forum.dlang.org/thread/hapxxhusoniimfxie...@forum.dlang.org I had some time today and headed over to Github to see if I could help out. But I'm not sure what I can do if I don't have the power to approve PRs. I'm not asking for that power, I haven't earned it yet. I'm just asking what it is I can do to help, especially on PRs that already have comments from a bunch of people. Should I add comments to the ones that don't? Work on my own PRs instead? Atila
Re: extern(C) symbol conflicts
On 1/28/15 2:49 AM, Walter Bright wrote:
On 1/27/2015 11:22 PM, Jacob Carlborg wrote:
On 2015-01-27 21:31, Steven Schveighoffer wrote:
For instance, if one library tags it as pure, but another does not. I
think an error in that case is warranted.
Yeah. Do the compiler need to look at the parameters as well? Even if
you put
const or immutable, it won't make difference on the C side. But it
will probably
be confusing if one is declared const and another is not.
C does not have name mangling, so:
extern(C) void foo(int);
extern(C) void foo(char);
will mangle to the same name, although D will regard them as different
symbols. C++ treats externC names the same way.
Hah! so this actually makes me more convinced we should do it differently:
cfile.c
#include stdio.h
void cfunction() {printf(hello\n);}
file1.d
module file1;
extern(C) void cfunction(int);
file2.d
module file2;
extern(C) void cfunction(const char *);
main.d
import file1;
import file2;
void main()
{
cfunction(1);
cfunction(1);
}
This works, and prints hello twice.
I really think D should consider extern(C) functions as not
overloadable, and universally binding (i.e. it's not an error to have 2
identical definitions in separate modules, and it is an error to have 2
different overloads of an extern(C) fucntion). Is there a good reason to
do it the current way besides that's what C++ does?
-Steve
[Issue 14077] New: Issue 14070 - Letting compiler determine length for fixed-length arrays in return type
https://issues.dlang.org/show_bug.cgi?id=14077
Issue ID: 14077
Summary: Issue 14070 - Letting compiler determine length for
fixed-length arrays in return type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Possible case:
int[$] returnSArr()
{
return [1, 2];
}
--
Re: Interfacing D to existing C++ code
Walter how far did you get to integrate with the STL ? I started writing std::vector and std::string (linux gcc libstdc++) but maybe someone already made progress on this. It's harder than I thought and will probably require a lot of work to maintain all implementations.
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source it
seems to have a different goal though. dson looks like it is an
alternative to std.json. Painlessjson is meant to make it easier
to use json, by automatically (de)serializing objects/structs and
converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of std.json
as a basis for Painlessjson.
[Issue 14075] New: [REG2.067a] ICE with ambiguous overloading functions without body
https://issues.dlang.org/show_bug.cgi?id=14075
Issue ID: 14075
Summary: [REG2.067a] ICE with ambiguous overloading functions
without body
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: sinkuup...@gmail.com
A regression introduced in
https://github.com/D-Programming-Language/dmd/pull/4309
struct Foo
{
auto opAssign(this X)(ref typeof(this));
auto opAssign(this X, V)(ref V) if (!is(V == typeof(this)));
}
void test()
{
Foo src;
const(Foo) target;
static if (is(typeof(target = src))) {}
}
Compiling this code causes the compiler to segfault.
0x00429fe0 in OpOverload::visit (this=0x7fffcee0, e=0x77ec85a0)
at opover.c:692
692m.lastf-toChars());
--
Re: Threads and stdio and HANDLE
On Wednesday, 28 January 2015 at 11:50:46 UTC, Danny wrote:
Hello,
I'm trying to write some toy examples using threads in D.
Is the std.stdio.File thread-local or shared? Is flockfile used
when I synchronize on it?
I tried checking phobos myself and found some things I don't
get (in stdio.d):
alias FLOCK = flockfile;
this(this) { @trusted
if(fps_)
FLOCK(fps_);
}
What is this(this)?
this(this) is the constructor syntax for construction of an
already
initialised struct. (sort of equivalent to the C++
class foo {
foo(const foo other)
{
...
}
} )
used like
struct somestruct
{
...
this()
{
writeln(calling this());
}
this(this)
{
writeln(calling this(this));
}
}
...
auto foo = somestruct(); //prints calling this()
auto baz = foo; //prints calling this(this)
If I want to write to stdout from a thread, do I use
LockingTextWriter? File? shared File? Does each thread have the
same stdout?
Yes
Finally, I'm trying to come to grips with shared:
What does specifying shared class or shared struct do?
all methods are marked as shared
(similar to what final class quux { ... } does compared to just
class quux { ... } )
The first use of shared is to signal to the compiler that it
should not store the variable in thread-local storage. But when
I acquire a lock (using synchronized, say), I'm supposed to
cast away the shared, right?
IIRC ,yes.
as in
class Bar { ... }
auto foo(shared Bar bar)
{
synchronized(bar) //acquire lock
{
Bar not_shared_bar = cast(Bar) bar;
...
//use not_shared_bar here as thread local.
// No races can occur because of the lock.
// DO NOT allow references to non_shared_bar to escape
// as using them outside the synchronised could lead to
racing
}
}
Does it then still know that it's not thread-local (but that I
ensured that nobody else accesses it for the time being)?
No. it's up to you to make sure that no non-shared references
escape
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven
wrote:
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is
variables that don't use @attribute syntax. This is not
something I invented, it follows on from existing uses of
@attributes and __keywords already supported by dmd.
Nick I'm putting together the FAQ right now. I don't quite
understand this proposal. Could you outline it for me? I'd like
to know exactly what words would require an '@' symbol. What is
the criteria for when to use an '@' and when not to use one?
This current rule is (use '@' if it is not a keyword)...so what
would the new rule be? Thanks.
Re: FAQ for newbies who see pure @safe nothrow @nogc
About the lists Qualifiers : const (can be an method attribute), immutable (can be an method attribute), inout, shared, (scope ?) Attributes : const (can be a type qualifier), immutable (can be a type qualifier), final (even so I don't understand why private final is so special), pure, @nothrow, @property, @nogc,... Neither qualifier nor attributes : abstract, override,... and many others Why override is not a method attribute...because if you remove it you've change the semantic of the code...final doesn't change anything if you remove it. To me, a function/method attribute enforce a behaviour on the function but you should be able to remove it without changing the semantic.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:50:23 UTC, matovitch wrote: About the lists Qualifiers : const (can be an method attribute), immutable (can be an method attribute), inout, shared, (scope ?) Attributes : const (can be a type qualifier), immutable (can be a type qualifier), final (even so I don't understand why private final is so special), pure, @nothrow, @property, @nogc,... Neither qualifier nor attributes : abstract, override,... and many others Why override is not a method attribute...because if you remove it you've change the semantic of the code...final doesn't change anything if you remove it. To me, a function/method attribute enforce a behaviour on the function but you should be able to remove it without changing the semantic. I'll need a better definition of what a qualifier/attribute is. It's ok to use words like qualifier and attribute when discussing ideas, but I'm trying to document how this idea would really affect everything so I need a solid definition of what you mean by a qualifier and an attribute. You said an attribute enforces a behavior on the function but you should be able to remove it without changing the semantics. What do you mean by semantics, because under my definition of semantics, removing a function qualifier does change the semantics. Maybe a better definition is, removing it doesn't change the logic of the function? Not sure. Maybe you can come up with a better definition. Thanks.
Re: Overloading equality operator for classes
On Thursday, 29 January 2015 at 17:48:04 UTC, rumbu wrote:
bool opEquals(Object obj, int value)
{
//do something to compare them
return false;
}
void main(string[] args)
{
Object obj;
if (obj == 12) {}
//ERROR function object.Object.opEquals (Object o) is not
callable using argument types (int)
}
According to paragraph (2) -
http://dlang.org/operatoroverloading.html#eqcmp), the compiler
must try obj.opEquals(12) and 12.opEquals(obj) but this is not
happening.
Is there any other way to overload the equality operator?
(except overriding opEquals in each class intended to be
compared with an integer)
UFCS is not used when operators are involved. I think this is
intentional.
Re: Check if type is from specific template?
On Thu, Jan 29, 2015 at 12:58:46PM +, Tofu Ninja via Digitalmars-d-learn wrote: [...] Incidentally, while trying to see how its used I found that a lot of the links on the std.traits doc page do not work and have no documentation. [...] Please file bugs for these. We need to fix the docs. T -- I speak better English than this villain Bush -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information
Overloading equality operator for classes
bool opEquals(Object obj, int value)
{
//do something to compare them
return false;
}
void main(string[] args)
{
Object obj;
if (obj == 12) {}
//ERROR function object.Object.opEquals (Object o) is not
callable using argument types (int)
}
According to paragraph (2) -
http://dlang.org/operatoroverloading.html#eqcmp), the compiler
must try obj.opEquals(12) and 12.opEquals(obj) but this is not
happening.
Is there any other way to overload the equality operator? (except
overriding opEquals in each class intended to be compared with an
integer)
Re: How can I help with pull requests if I don't have the authority to merge?
On Thu, Jan 29, 2015 at 01:42:13PM +, Atila Neves via Digitalmars-d wrote: After this thread: http://forum.dlang.org/thread/hapxxhusoniimfxie...@forum.dlang.org I had some time today and headed over to Github to see if I could help out. But I'm not sure what I can do if I don't have the power to approve PRs. I'm not asking for that power, I haven't earned it yet. I'm just asking what it is I can do to help, especially on PRs that already have comments from a bunch of people. Should I add comments to the ones that don't? Work on my own PRs instead? [...] You don't need commit privileges to review PR's. We need more eyes to look at the code that's going into D, a lot more eyes. You can just leave comments on the PR page, saying that you reviewed it and it looks good to merge (LGTM), or if you find issues or flaws, point them out. Similarly if you have an idea of how to improve the PR, suggest it. Of course, you can't merge the PR unless you have commit privileges, but generally speaking we're more short of reviewers than committers. We need all the help we can get! T -- In order to understand recursion you must first understand recursion.
New Wiki page to save time in the forums
The recent thread about how to solve the problem of odd looking function attributes gave me an idea to have a page that explains why certain decisions were made in the language. Instead of having to write a long thought out response every time someone asks a question who isn't aware of previous discussion, you can respond with a link to the page. I've created such a page in the wiki! http://wiki.dlang.org/Language_Designs_Explained Currently the explanations are in the form of FAQ. I left one question unanswered since I don't know the answer so I encourage someone who does to check it out and fill it in :) Since a wiki page is not the same as a forum post, I would like to encourage people who add questions and answers to be as detailed as necessary. No one wants to read a novel but every detail you leave out will end up making someone come back to the forums to ask about whatever was missing from the page.
Re: What is @return?
On Thursday, 29 January 2015 at 05:02:58 UTC, ketmar wrote: http://wiki.dlang.org/DIP25 this is a very recent thing, it wasn't coded when 2.066 was released. Thanks, I like it.
Re: extern(C) symbol conflicts
On 01/29/15 14:43, Steven Schveighoffer via Digitalmars-d wrote: I really think D should consider extern(C) functions as not overloadable, All functions are overloadable in D; ie you can mix C and D overloads freely; this is a feature. It allows you to extend the C i/f without adding an extra layer of pointless wrappers. And export a subset of the D i/f to other C-but-not-D-aware languages. Etc. and universally binding (i.e. it's not an error to have 2 identical definitions in separate modules, External functions with identical signatures and identical mangled names are obviously not conflicting, so that case does not need to be an error, yes. But I suspect that, in practice, sticking to just one declaration is a good idea anyway (the language changes with every compiler release, so the signatures can easily get out of sync. eg missing nothrow/@nogc/@return attributes). artur
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 17:51:06 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 17:32:30 UTC, Nick Treleaven
wrote:
No, the idea proposed was:
@safe @override const func();
@abstract class C{}
const var = 5;
__gshared gvar = 4;
const is never @const. @abstract is always @abstract. It is
variables that don't use @attribute syntax. This is not
something I invented, it follows on from existing uses of
@attributes and __keywords already supported by dmd.
Nick I'm putting together the FAQ right now. I don't quite
understand this proposal. Could you outline it for me? I'd
like to know exactly what words would require an '@' symbol.
What is the criteria for when to use an '@' and when not to use
one? This current rule is (use '@' if it is not a
keyword)...so what would the new rule be? Thanks.
Does it really matter ? Please put your first post in there and
be done with it. These proposal are not gonna happen anyway (the
ROI is simply not there).
Re: accept @pure @nothrow @return attributes
On 2015-01-28 23:27, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. A good language design that doesn't require the ; statement terminator would recognize void func() as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. -- /Jacob Carlborg
Re: How can I help with pull requests if I don't have the authority to merge?
On 1/29/15 8:42 AM, Atila Neves wrote: After this thread: http://forum.dlang.org/thread/hapxxhusoniimfxie...@forum.dlang.org I had some time today and headed over to Github to see if I could help out. But I'm not sure what I can do if I don't have the power to approve PRs. I'm not asking for that power, I haven't earned it yet. I'm just asking what it is I can do to help, especially on PRs that already have comments from a bunch of people. Should I add comments to the ones that don't? Work on my own PRs instead? Reviewing is available to everyone. In general, it takes 2 reviewers to approve a PR, but only one of those has to have commit capabilities. As long as we know 2 sets of eyes have seen it and approve, it doesn't matter that one of those sets doesn't have commit permissions. H.S. Teoh (@quickfur) got his wings by reviewing and submitting PRs. -Steve
Re: DlangUI
On Wednesday, 28 January 2015 at 14:21:36 UTC, Vadim Lopatin wrote: On Wednesday, 28 January 2015 at 13:37:34 UTC, John Colvin wrote: On Wednesday, 28 January 2015 at 10:57:57 UTC, Vadim Lopatin wrote: BTW, could you try on mac https://github.com/buggins/dlangide.git as well? It's dlangui-based D language IDE I'm currently working on. That works OK. The text is all horrible looking. This is probably due to (lack of) scaling support for high-res screens (retina). Is graphics scaled too? If so, it's due to scaling. Otherwise possible it's due to bad implementation of subpixel antialiasing (aka ClearType). I've submitted fix to disable subpixel antialiasing. An example of what I see (with up-to-date git HEAD) https://www.dropbox.com/s/49n9m0b9uutzaa8/Screenshot%202015-01-29%2014.11.57.png?dl=0
Re: accept @pure @nothrow @return attributes
On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-28 20:07, Jonathan Marler wrote: You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. By that definition basically all declarations in the object module is a keyword :) -- /Jacob Carlborg
Re: painlessjson released, looking for improvement advice
On Thursday, 29 January 2015 at 13:44:04 UTC, Pierre Krafft wrote:
On Thursday, 29 January 2015 at 13:16:48 UTC, BlackEdder wrote:
On Thursday, 29 January 2015 at 00:24:44 UTC, rlonstein wrote:
Not quite the same, but I've been using dson
(https://github.com/w0rp/dson).
Have you looked it over?
Did not know about that one. From looking through the source
it seems to have a different goal though. dson looks like it
is an alternative to std.json. Painlessjson is meant to make
it easier to use json, by automatically (de)serializing
objects/structs and converting them to (and from) json.
For example:
class Point
{
double x;
double y;
}
void main()
{
auto pnt = new Point( 1,2 );
auto jsonPnt = toJSON( pnt ); // Returns a JSONValue( { x:
1.0, y: 2.0 } )
auto nPnt = fromJSON!Point( jsonPnt );
assert( nPnt.x == pnt.x nPnt.y == pnt.y );
}
I guess it would be interesting to use dson instead of
std.json as a basis for Painlessjson.
I believe we should continue using std.json, and instead push
for taking dson (or its lessons learned) into phobos if it's a
better implementation. The best general solution should be the
one that is available out of the box.
Yeah, I was wondering, if you have to import std.json and use it
as a basis for painlessjson, is it really so big an improvement?
Especially since std.json might be replaced (sooner or later).
I'd prefer an easy to use implementation that replaces std.json
completely.
(I don't want to slight the work done on painlessjson and it
might come in handy here and there. Maybe it could be added to
the std.json module?)
Re: What is @return?
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote:
@property auto info() @safe @nothrow @pure @return const {
return this; }
It is mesmerizing... (@ _ @)
And soon its gong to look like this:
export @property auto info() @safe @nothrow @pure @return const {
return this; }
something weird with strerror_r
Recently, I found something really weird when I use strerror_t
function which is declared inside std.c.string.
The code snippet is listed below:
import std.c.string;
import core.stdc.errno;
void main() {
import std.stdio;
char[128] buf;
strerror_r(errno, buf.ptr, buf.sizeof);
writeln(cast(string)buf);
}
The terminal should print Success with errno=0, but in this
example, the result is
.
I test this snippet both on Archlinux and Ubuntu 14.04.1, and the
result is same. If there is someone can help me?
I wanna know if it is my mistake or it is just a bug.
Thx!
Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 08:45:23 UTC, Manu wrote: I'm not convinced that D needs a custom GUI library though. That's a behemoth effort. Indeed, but I find there's still quite a bit of value in even a small wrapper that just pops up a window and lets you do the basic drawing and input. My simpledisplay.d sets a low bar like that and I find it to be of enormous use. (I'll probably be writing about it in the this week in D series very soon.)
Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 11:17:32 UTC, Mike wrote: Is the concept of a *window* even that platform agnostic? Is writeln even platform agnostic? I've used targets where it doesn't do anything including Microsoft Windows with the gui subsystem. Generally, I think it is a mistake to reject something that is good for a great many users just because it isn't available everywhere. If it isn't right for your target, just don't use it. I would caution against requiring the support libs in Phobos; we don't want programs to fail to start because Xlib isn't installed, for example. But there's ways to do that. I thought that was mostly a desktop metaphor. Any call to a create window function might fail at runtime, on a platform with no graphics support, all window creation can throw an exception. On a platform with just one screen, any beyond the first might throw. A gui toolkit would probably need to do something about that to keep things like pop-up message and dialog boxes working, but for the basic stuff just saying it might throw should be good enough.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:10:12 UTC, Jonathan Marler wrote: On Thursday, 29 January 2015 at 10:43:37 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:38:46 UTC, matovitch wrote: On Thursday, 29 January 2015 at 10:34:37 UTC, matovitch wrote: On Wednesday, 28 January 2015 at 22:32:55 UTC, Jonathan Marler wrote: Why don't we make all the function attributes keywords? --- As a newbie, I would have asked the reversed question : Why don't we make all the function attributes attributes? To be clear, what are the avantages of keywords vs attributes ? Why should the most used function attributes be keywords ? In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence. JM Davis Ok ! I'm not sure I understand your question. Why don't we make all the function attributes attributes? Is this what you mean? Why don't we require an '@' symbol before all function attributes? Yes, if @ttributes are better because you can create identifier with the same name why aren't they used everywhere ? By the way, the denomination makes sense too : function attibutes are either built-in or user defined attributes. But const can be a qualifier or a function/method attribute that is two very different things...maybe not beeing able to use const as a function attribute but @const would make more sense ?
[Issue 14077] Letting compiler determine length for fixed-length arrays in return type
https://issues.dlang.org/show_bug.cgi?id=14077
--- Comment #3 from monkeywork...@hotmail.com ---
(In reply to bearophile_hugs from comment #2)
(In reply to monkeyworks12 from comment #1)
(In reply to Kenji Hara from comment #0)
Possible case:
int[$] returnSArr()
{
return [1, 2];
}
Also consider the following:
auto[$] returnSArr()
{
return [1, 2];
}
const[$] returnSArr()
{
return [1, 2];
}
//Etc.
int[auto] returnAA()
{
return [asdf:1];
}
auto[auto] returnAA()
{
return [asdf:1];
}
immutable[auto[$]] returnAA()
{
return [[1, 2]:1];
}
What are the use cases for all this? Implementation efforts have a cost in
time.
I just put them here for completeness in case any were overlooked. I'm not
specifically requesting that they are implemented as well.
--
Re: Import paths do not work
On Thursday, 29 January 2015 at 10:26:56 UTC, Atila Neves wrote: I would suggest instead of using make, use dub[0] build manager instead. It'll handle grabbing all the files and compiling them correctly. [0] http://code.dlang.org/package-format Or for simple projects such as this one seems to be, just use rdmd. Atila I am using Mono-D on MonoDevelop. I was normally keeping all library files in the same project. But copying same library codes between different projects didn't seem like a good idea. Then I copied library files as symbolic link to project, but this time, if I put a new module in library folder, Mono-D doesn't see it automatically. Then I saw Include part in project properties which uses -I flag while compiling the project. I removed all symbolic links from project, and added full folder paths of libraries to that Include list. As you can guess, as I asked in the question, it doesn't see library files now. I still have a solution as linking to library modules, but I wondered whether it was possible in another easier way.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used everywhere
? By the way, the denomination makes sense too : function
attibutes are either built-in or user defined attributes. But
const can be a qualifier or a function/method attribute that
is two very different things...maybe not beeing able to use
const as a function attribute but @const would make more sense
?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in the
other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of them
for the sake of consistency. The problem with this idea is
that you've now introduced inconsistency somewhere else. Every
keyword that you put an '@' symbol in front of, will be used
somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use
'@' if it is not a keyword. Now it's, Use '@' if it is not a
keyword except when it's a function attribute. This
definition will likely be made worse since people will want to
solve the newly introduced inconsistencies. So the new
definition will become, Use '@' if it is a keyword except if
it's a function attribute or a class specifier. By the time
you solve every inconsistency you'll have made every usage of
every keyword use the '@' symbol. Then the rule will be
Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to distinguish
beetween qualifiers and attributes. But I understand legacy code
is an issue and I agree that the FAQ should just state the facts.
[Issue 14077] Letting compiler determine length for fixed-length arrays in return type
https://issues.dlang.org/show_bug.cgi?id=14077
monkeywork...@hotmail.com changed:
What|Removed |Added
CC||monkeywork...@hotmail.com
--- Comment #1 from monkeywork...@hotmail.com ---
(In reply to Kenji Hara from comment #0)
Possible case:
int[$] returnSArr()
{
return [1, 2];
}
Also consider the following:
auto[$] returnSArr()
{
return [1, 2];
}
const[$] returnSArr()
{
return [1, 2];
}
//Etc.
int[auto] returnAA()
{
return [asdf:1];
}
auto[auto] returnAA()
{
return [asdf:1];
}
immutable[auto[$]] returnAA()
{
return [[1, 2]:1];
}
--
[Issue 14077] Letting compiler determine length for fixed-length arrays in return type
https://issues.dlang.org/show_bug.cgi?id=14077
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #2 from bearophile_h...@eml.cc ---
(In reply to monkeyworks12 from comment #1)
(In reply to Kenji Hara from comment #0)
Possible case:
int[$] returnSArr()
{
return [1, 2];
}
Also consider the following:
auto[$] returnSArr()
{
return [1, 2];
}
const[$] returnSArr()
{
return [1, 2];
}
//Etc.
int[auto] returnAA()
{
return [asdf:1];
}
auto[auto] returnAA()
{
return [asdf:1];
}
immutable[auto[$]] returnAA()
{
return [[1, 2]:1];
}
What are the use cases for all this? Implementation efforts have a cost in
time.
--
Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 14:45:19 UTC, Adam D. Ruppe wrote: Is writeln even platform agnostic? I've used targets where it doesn't do anything including Microsoft Windows with the gui subsystem. Sure it does, it's just that by default the stdio handles are closed. You can still run your program with MyGuiProgram.exe output.txt, or open them in your program. I would consider writeln platform agnostic, it's just that it may not always be a console that it writes to.
Re: Window creation, for phobos?
On Thursday, 29 January 2015 at 11:24:22 UTC, Tofu Ninja wrote: On Thursday, 29 January 2015 at 08:09:16 UTC, user wrote: Apparently this is only my issue, all others seems to be ok with no GUI in phobos. NO... I am not ok with no GUI in phobos. I am with you. I ensure you there are many more waiting for standard gui library. I think this can be a killer feature for D. For now I use QT for gui and would be happy to switch to D ASAP. Piotrek
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create identifier
with the same name why aren't they used everywhere ? By the
way, the denomination makes sense too : function attibutes are
either built-in or user defined attributes. But const can be a
qualifier or a function/method attribute that is two very
different things...maybe not beeing able to use const as a
function attribute but @const would make more sense ?
The purpose of this thread wasn't to re-discuss what was already
discussed. The answer to your idea can be found in the other
thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and @nogc
and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of them
for the sake of consistency. The problem with this idea is that
you've now introduced inconsistency somewhere else. Every
keyword that you put an '@' symbol in front of, will be used
somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use '@'
if it is not a keyword. Now it's, Use '@' if it is not a
keyword except when it's a function attribute. This definition
will likely be made worse since people will want to solve the
newly introduced inconsistencies. So the new definition will
become, Use '@' if it is a keyword except if it's a function
attribute or a class specifier. By the time you solve every
inconsistency you'll have made every usage of every keyword use
the '@' symbol. Then the rule will be Always use the '@'
symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
Re: FAQ for newbies who see pure @safe nothrow @nogc
On 1/29/15 7:03 AM, Jonathan Marler wrote: On Thursday, 29 January 2015 at 04:16:30 UTC, Jesse Phillips wrote: It would be somewhere under: http://wiki.dlang.org/ Maybe Documentation = Language Design Explanation? Anyone else for or against this? If no one protests I can create it, along with the FAQ from matovich and including Walters extra explanation about increasing redundancy. Just do it. -- Andrei
Re: FAQ for newbies who see pure @safe nothrow @nogc
On Thursday, 29 January 2015 at 16:02:44 UTC, matovitch wrote:
On Thursday, 29 January 2015 at 15:54:54 UTC, Jonathan Marler
wrote:
On Thursday, 29 January 2015 at 15:39:18 UTC, matovitch wrote:
Yes, if @ttributes are better because you can create
identifier with the same name why aren't they used everywhere
? By the way, the denomination makes sense too : function
attibutes are either built-in or user defined attributes. But
const can be a qualifier or a function/method attribute that
is two very different things...maybe not beeing able to use
const as a function attribute but @const would make more
sense ?
The purpose of this thread wasn't to re-discuss what was
already discussed. The answer to your idea can be found in
the other thread
http://forum.dlang.org/post/rtwbtxigfeupvykpb...@forum.dlang.org.
It's gonna be a long read so I'll summarize what I believe is
the correct answer.
The problem we are trying to solve is that the function
attributes are inconsistent. Some use @ like @safe and
@nogc and some don't like pure and nothrow.
So one idea is to require an '@' symbol in front of all of
them for the sake of consistency. The problem with this idea
is that you've now introduced inconsistency somewhere else.
Every keyword that you put an '@' symbol in front of, will be
used somewhere else without an '@' symbol. Like this:
abstract class MyClass { }
@abstract void myfunc();
See the inconsistency? You're gonna end up with alot of these
types of inconsistencies. In addition, you've made the rule of
when to use the '@' symbol more complex. Before it was, Use
'@' if it is not a keyword. Now it's, Use '@' if it is not
a keyword except when it's a function attribute. This
definition will likely be made worse since people will want to
solve the newly introduced inconsistencies. So the new
definition will become, Use '@' if it is a keyword except if
it's a function attribute or a class specifier. By the time
you solve every inconsistency you'll have made every usage of
every keyword use the '@' symbol. Then the rule will be
Always use the '@' symbol.
This will definitely be included on the FAQ :) I'll reword it
and modify it but I agree that people will want an explanation
for this.
One can argue that it's hard to remember what is a keyword
(especially in D where there are many) and easier to
distinguish beetween qualifiers and attributes. But I
understand legacy code is an issue and I agree that the FAQ
should just state the facts.
This doesn't really have to do with Legacy code. You can always
support both ways for a time and deprecate the old way. It
appears my answer did not address your idea well enough. I'll
have to put together a better explanation. In the mean time,
could you help me by giving me the gritty details of your idea.
I know others will also want an explanation for this so I'd like
to include one in the FAQ so as to prevent us from explaining the
same thing over and over. You idea was to put '@' on words if
they are attributes and to omit them on qualifiers. Could you
list what words are qualifiers and what words are attributes? I
don't think this idea would work but hey, maybe you'll prove me
wrong, I'll admit I haven't gone through the details of what
problems this idea would create.
