Re: We need an internal keyword.
On Sun, 21 Oct 2018 08:40:36 +, Laurent Tréguier wrote: > This is by design; the D way of dealing with this would be to split the > module into a package with multiple modules. This is often a usable way of doing things, but sometimes not so much. If you're writing a script for use with dub --single or rdmd, you lose a lot of convenience if you use multiple files. It might also take a lot of time to split things up once static constructors get involved.
Re: D alternative for node.js's socket.IO?
On Sun, 21 Oct 2018 20:58:23 +, Fleel wrote: > Can std.socket provide a realtime connection between the client(web > browser) and the server, like for a chatroom or realtime multiplayer > game? Yes, but it will be a bit of work -- you'd need to implement a webserver by hand that can upgrade an HTTP request to a websocket. It probably wouldn't be *that* hard, but vibe.d already has support for both HTTP servers and websockets. This does mean changing the javascript code, but from what I saw last time I used it, socket.io provides little advantage over plain websockets.
Re: shared - i need it to be useful
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote: > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d > wrote: >> Note that there may well be a good way to get the good properties of MP >> without breaking the type system, but MP itself is not good because it >> breaks @safe. > > Show me. Nobody has been able to show that yet. I'd really like to know > this. If we only used your proposal and only used @safe code, we wouldn't have any data races, but that's only because we wouldn't have any shared data. We'd have shared *variables*, but they would not contain any data we could read or alter, and that's pretty much useless. To use your proposal, we need to cast data back from shared to unshared. When it's unshared, we need to make sure that exactly one thread has a reference to that data as unshared. And @safe *should* help us with that. Currently, it helps because casting unshared to shared is not @safe, because it makes it trivial to get multiple threads with unshared references to the same data. And that's when you're using shared as expected rather than doing something weird.
Re: Passing $ as a function argument
On 10/10/2018 01:46 AM, James Japherson wrote: Would be nice to be able to pass $ as a function argument to be used in automatic path length traversing. $ only works in indexing operations because that's required to figure out what it refers to. However, you can mostly use it as a readonly variable there, with the caveat that you can't refer to it directly from function literals.
Re: A Friendly Challenge for D
On 10/10/2018 03:05 PM, Jabari Zakiya wrote: https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ It would be great if you could provide a link to a freely downloadable version of this.
Re: Passing $ as a function argument
On 10/10/2018 05:01 PM, James Japherson wrote:
All I'm proposing is to to allow one to escape that syntax to function
calls.
foo(int index)
{
return arr[index];
}
and D can support
foo($-1);
which simply gets translated in to
arr[arr.length - 1]
I think you might have a misunderstanding about how $ works.
$ is a variable of type size_t. It's an integer. It is syntactic sugar.
You can't pass $ as a special value; it's expanded to refer to a
specific array at compile time, and it's an alias to the .length
property of that array. In order to pass it to a function, you need an
array as context.
Right now, the compiler looks at the enclosing index expression and uses
it to determine the value to pass.
You want it to look into the function you're calling to determine the
value to pass.
It's obvious what you want it to do in this particular case -- the
compiler should track where that function parameter is used, find the
relevant array, and use it to get the length to pass. How about:
module a;
extern(C) int foo(int index)
{
return someGlobalArray[index];
}
module b;
extern(C) int foo(int index);
void main() { foo($); }
The compiler doesn't have access to the function body to determine what
array you're talking about.
Or:
int foo(int index)
{
if (someCondition)
return someGlobalArray[index];
else
return someOtherArray[index];
}
foo($);
There are two arrays you could be talking about, potentially of
different lengths, and the compiler can't tell which you're going to access.
Or:
int foo(int index)
{
int something = index;
return someGlobalArray[something];
}
The compiler can't just track how the `index` variable is used; it has
to track how every variable is used and where it can get its value. This
gets complicated fast.
Or:
int foo(int index)
{
return std.process.environment["PATH"].split(":")[index];
}
The compiler has to execute the bulk of this function at runtime in
order to figure out what value to pass to it.
Your proposal only works in the most trivial cases. Because of that, if
we made that change, you'd try using it at call sites, then the function
definition would change slightly and your code would break.
It's generally not good for a programming language to have brittle
features like that.
Re: This is why I don't use D.
On 10/06/2018 01:38 AM, 0xEAB wrote: The "tests" check doesn't seem to work properly for DMD <= v2.072.0. If one looks at the reports[0] for those compilers, one will that pretty everything failed. For example, `discord-rpc`[1] doesn't even have any unittests. I'm clearing out those build results so we'll rerun them. This should get proper error reports as well (they're working at last!). I've also moved the project to proper hosting, which should slow it down even more but provide better security.
Re: Static foreach bug?
On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote: On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh wrote: On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote: Woud be so much more maintainable if I could have each statement into a variable that could be maintained properly. You could extract the body of the static foreach into a [template] function. I'm aware of that, but it's an unnecessary work around for something as trivial as the alternative would have been. You would need to mark symbols as scoped to the static foreach body, or else as exported from a scope to an outer scope. So it's not exactly trivial.
Re: Static foreach bug?
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote: Woud be so much more maintainable if I could have each statement into a variable that could be maintained properly. You could extract the body of the static foreach into a [template] function.
Re: Half-baked thought: Out-of-process asserts
On Tuesday, 4 September 2018 at 03:39:04 UTC, Nick Sabalausky (Abscissa) wrote: Discussion questions: - What would be the feasibility of the various parts of this? You'd need to interrupt the process. You'd need a parent process that detects the interrupt. Then you'd need to use the debugger API to attach to the child process and get the relevant data. Annoying to write, but it should work, assuming the child process didn't install a signal handler to handle SIGABRT. You could simply call SIGABRT and create a core dump, but that can be costly on a system where your application might use multiple gigabytes of RAM. - What would be the downsides, and how serious would they be? It's extra complexity. It means you must run in a multiprocessing environment (which is almost, but not quite, a trivial requirement). If you're running as a user without debugger privileges, you're horked; you aren't getting an error message at all. The benefit is that you can safely do more elaborate logging when more of your runtime and base frameworks are in an invalid state. I think most people are happy to live dangerously or to go with simpler logging.
Re: Truly @nogc Exceptions?
On Thursday, 20 September 2018 at 15:52:15 UTC, H. S. Teoh wrote: Yeah, that's what I meant. :D Well, for backward compatibility we could still have .msg allocate and return a string, but we could provide an overload / alternate member function that writes directly to a sink instead. Then we don't ever have to allocate unless the sink itself does. I believe Tango did this a decade ago. It's a solid strategy. However, with Tango, the default was to implement the toString(sink) function by calling the regular toString(), which was quite convenient but won't work with @nogc.
Re: Jai compiles 80,000 lines of code in under a second
On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote: Alo! I just watched this talk from Jonathan Blow [0] about his programming language called Jai, and he can now compile an 80,000 line game in about 1.5 seconds on a laptop (of course I have no idea what laptop he's using), under 1 second on a desktop. Jai is in the hands of maybe a dozen people and , so it's hard to compare. But with a sufficiently simple language with no metaprogramming, 80k lines of code in 1.5 seconds seems doable. And in that situation, dmd does just fine -- 0.73 seconds to compile 84k lines of simple generated code on i5 2400, or 0.20 seconds with -c -o-. It's just that D code tends toward heavy metaprogramming. That's a lot safer (consider C-style varargs writefln versus the template version), and it's slower to compile. On a related note: He also mentions some really cool compilation features like having compiler hooks that tell you when compilation is done, when executable and where it will be written so you can create your build recipe inside the program itself. Also allows you do do things like: whenCompilationFinishes(exeLocation) => loadExecutableIcon(myIcon, exeLocation) During the build! Your source knows how to build itself as a concept is awesome! There's actually a D runner [1] that kind of allows for source files to set stuff up. It's awesome for demos and terrible otherwise. It takes "it builds on my machine" to a new level.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote: Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/. A quick status update: Per-package reports and build badges are now a thing. http://ikeran.org/report/package/accessors.html Dunno if anybody would want a build badge, but it's there. And a bit big. Oh well. Backfill has gotten all .0 releases from 2.069.0 forward. I'm cutting off the backfill for point releases at 2.080.1, about two days from now. 19 compilers rather than 43 makes this project a bit more sustainable. (It was previously taking six hours to build a single compiler release, but with some changes, it started taking 16.) After the backfill finishes, I'll start grabbing new dub packages, which will be trivial. The next tasks are auto-detecting new DMD versions (pretty straightforward) and making machine-readable output. As an aside, the current output is about 50MB of HTML and SVG, served as static files. I thought of using arsd's cgi.d, but there really isn't a point for now.
Re: Jai compiles 80,000 lines of code in under a second
On Friday, 21 September 2018 at 13:28:47 UTC, aliak wrote: Sure, all true, but from what I've seen of Jai, it's not a simple language, and it does a decent amount of compile time stuff, but who knows, maybe the code is simple indeed. I remember a demo where he ran a game at compile time and was also fast AFAIR. I think that his goal is to keep it fast regardless of which features are used though. I hope. We don't have access to the source code being tested. We don't have access to the compiler. Until the language is actually made public, we can't make any substantive conclusions about its speed.
Re: This is why I don't use D.
On Friday, 21 September 2018 at 20:49:54 UTC, 0xEAB wrote: On Thursday, 20 September 2018 at 17:06:43 UTC, Neia Neutuladh wrote: The tester is now submodule-aware and I removed builds for packages with a `.gitmodules` file. I'm not sure whether this is actually a good idea. There are some projects that support both, DUB and submodules+makefile. Those would (unnecessarily) get excluded. I meant that I removed the past builds for things with git submodules so that they could be rebuilt. Stderr is captured now, but I believe I messed up the UI for it. C'est la vie.
Re: Updating D beyond Unicode 2.0
On Friday, 21 September 2018 at 23:17:42 UTC, Seb wrote: A: Wait. Using emojis as identifiers is not a good idea? B: Yes. A: But the cool kids are doing it: The C11 spec says that emoji should be allowed in identifiers (ISO publication N1570 page 504/522), so it's not just the cool kids. I'm not in favor of emoji in identifiers. In all seriousness I hate it when someone thought its funny to use the lambda symbol as an identifier and I have to copy that symbol whenever I want to use it because there's no convenient way to type it. It's supported because λ is a letter in a language spoken by thirteen million people. I mean, would you want to have to name a variable "lumиnosиty" because someone got annoyed at people using "i" as a variable name?
Re: Updating D beyond Unicode 2.0
On Friday, 21 September 2018 at 20:25:54 UTC, Walter Bright wrote: But identifiers? I haven't seen hardly any use of non-ascii identifiers in C, C++, or D. In fact, I've seen zero use of it outside of test cases. I don't see much point in expanding the support of it. If people use such identifiers, the result would most likely be annoyance rather than illumination when people who don't know that language have to work on the code. ...you *do* know that not every codebase has people working on it who only know English, right? If I took a software development job in China, I'd need to learn Chinese. I'd expect the codebase to be in Chinese. Because a Chinese company generally operates in Chinese, and they're likely to have a lot of employees who only speak Chinese. And no, you can't just transcribe Chinese into ASCII. Same for Spanish, Norwegian, German, Polish, Russian -- heck, it's almost easier to list out the languages you *don't* need non-ASCII characters for. Anyway, here's some more D code using non-ASCII identifiers, in case you need examples: https://git.ikeran.org/dhasenan/muzikilo
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 04:54:59 UTC, Joakim wrote: To wit, Windows linker error with Unicode symbol: https://github.com/ldc-developers/ldc/pull/2850#issuecomment-422968161 That's a good argument for sticking to ASCII for name mangling. I'm torn. I completely agree with Adam and others that people should be able to use any language they want. But the Unicode spec is such a tire fire that I'm leery of extending support for it. The compiler doesn't have to do much with Unicode processing, fortunately.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 12:24:49 UTC, Shachar Shemesh wrote: If memory serves me right, hieroglyphs actually represent consonants (vowels are implicit), and as such, are most definitely "characters". Egyptian hieroglyphics uses logographs (symbols representing whole words, which might be multiple syllables), letters, and determinants (which don't represent any word but disambiguate the surrounding words). Looking things up serves me better than memory, usually. The only language I can think of, off the top of my head, where words have distinct signs is sign language. Logographic writing systems. There is one logographic writing system still in common use, and it's the standard writing system for Chinese and Japanese. That's about 1.4 billion people. It was used in Korea until hangul became popularized. Unicode also aims to support writing systems that aren't used anymore. That means Mayan, cuneiform (several variants), Egyptian hieroglyphics and demotic script, several extinct variants on the Chinese writing system, and Luwian. Sign languages generally don't have writing systems. They're also not generally related to any ambient spoken languages (for instance, American Sign Language is derived from French Sign Language), so if you speak sign language and can write, you're bilingual. Anyway, without writing systems, sign languages are irrelevant to Unicode.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 12:35:27 UTC, Steven Schveighoffer wrote: But aren't we arguing about the wrong thing here? D already accepts non-ASCII identifiers. Walter was doing that thing that people in the US who only speak English tend to do: forgetting that other people speak other languages, and that people who speak English can learn other languages to work with people who don't speak English. He was saying it's inevitably a mistake to use non-ASCII characters in identifiers and that nobody does use them in practice. Walter talking like that sounds like he'd like to remove support for non-ASCII identifiers from the language. I've gotten by without maintaining a set of personal patches on top of DMD so far, and I'd like it if I didn't have to start. What languages need an upgrade to unicode symbol names? In other words, what symbols aren't possible with the current support? Chinese and Japanese have gained about eleven thousand symbols since Unicode 2. Unicode 2 covers 25 writing systems, while Unicode 11 covers 146. Just updating to Unicode 3 would give us Cherokee, Ge'ez (multiple languages), Khmer (Cambodian), Mongolian, Burmese, Sinhala (Sri Lanka), Thaana (Maldivian), Canadian aboriginal syllabics, and Yi (Nuosu).
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 08:52:32 UTC, Jonathan M Davis wrote: Unicode identifiers may make sense in a code base that is going to be used solely by a group of developers who speak a particular language that uses a number a of non-ASCII characters (especially languages like Chinese or Japanese), but it has no business in any code that's intended for international use. It just causes problems. You have a problem when you need to share a codebase between two organizations using different languages. "Just use ASCII" is not the solution. "Use a language that most developers in both organizations can use" is. That's *usually* going to be English, but not always. For instance, a Belorussian company doing outsourcing work for a Russian company might reasonably write code in Russian. If you're writing for a global audience, as most open source code is, you're usually going to use the most widely spoken language.
Re: Warn on unused imports?
On 09/26/2018 12:39 AM, FeepingCreature wrote: On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote: The DMD compiler is available as a library. A linter tool can be based on that. Repeating it here: the library does not have version-tagged releases. For a build system based around reproducible builds, this makes it completely unusable. It means you need to use git submodules and depend on a specific version that way. And that means you can't tell why you chose a particular revision.
Re: Warn on unused imports?
On 09/26/2018 02:51 AM, FeepingCreature wrote: On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic wrote: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. I can't put it differently than this: you're simply wrong, in my opinion. It's *provably impossible* do do this statically. I think you can do some amount of it statically: * List out the symbols each module exports. * List out the symbols that appear in source code. * If you find that a module doesn't export a symbol that this code uses, recommend its deletion. * If you encounter a mixin in a module that's visible to it, assume that module is required. (Optional: require that mixin to be at module scope.) * If you encounter a mixin in the module you're analyzing, give up. So that's at least 80 modules in Phobos that you might be able to suggest not importing.
Re: Calling nested function before declaration
On 09/26/2018 03:46 PM, Jonathan wrote:
I can't see how the current behavior is at all better or to be preferred
unless it is faster to compile? What is the reason for it being how it is?
void outerFunction()
{
func();
auto lock = acquireLock();
void nested()
{
}
}
Inside `nested`, can you refer to `lock`? It's in lexical scope, so yes.
It hasn't been initialized yet. What value should it have? Presumably
its standard uninitialized value.
This is likely to cause a lot of confusion.
The standard ways of dealing with this:
* Reorder the declarations.
* Make the functions non-nested.
* Get rid of mutual recursion.
* Use a delegate.
* Do a method-to-method-object refactoring.
Re: Updating D beyond Unicode 2.0
On 09/26/2018 01:43 PM, Walter Bright wrote: Don't most languages have a Romanji-like representation? Yes, a lot of languages that don't use the Latin alphabet have standard transcriptions into the Latin alphabet. Standard transcriptions into ASCII are much less common, and newer Unicode versions include more Latin characters to better support languages (and other use cases) using the Latin alphabet.
Re: D IDE
On 09/26/2018 08:23 PM, Nick Sabalausky (Abscissa) wrote: On 09/05/2018 01:34 PM, ShadoLight wrote: I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left! I sometimes wonder similar things about Vim/Emacs users, too ;) A lot of people use Vim/Emacs plus a full IDE. I use IntelliJ for work. I also use Vim. Vim is much better when I know my APIs, and it's exceptional at applying transformations to a block of text. IntelliJ is much better when I'm using an API I'm unfamiliar with. Sometimes I'll switch back and forth editing the same file -- I'll hack something together in Vim and then use IntelliJ to quickly find and fix errors. For D, unfortunately, I haven't gotten an IDE to work yet. Not with any appreciable degree of autocomplete. So I stick with Vim pretty much entirely. But don't forget, not all non-IDE people are Vim/Emacs. And just like IDE development, plain-editor development didn't stagnate either. Many non-IDE users (like me) use editors that are far more contemporary than Vim/Emacs and *don't* have that learning curve. Pretty much all advanced features in a text editor have a learning curve. Kind of unavoidable; we're asking text editors to do complex things. GUI editors can offer *less* of a learning curve, and they can offer advice better, but they can't eliminate it entirely. And for that matter, sometimes I get the impression that IDE users think non-IDE editors are far less capable than they really are. For the most part, "IDE" mostly just means: editor + GUI-based buildsystem + debugger. Autocomplete, highlighting errors, semantic code navigation, and displaying extra semantic information are other IDE features that text editors tend to lack. On the other hand, I've seen projects billing themselves as IDEs when they were pretty much just a tree view for files in the project, a GtkSourceView, and a build button.
Re: phobo's std.file is completely broke!
On Wednesday, 19 September 2018 at 08:54:42 UTC, Vladimir Panteleev wrote: BTW, something follows from the above: write(`C:\` ~ (short path) ~ `con`) will fail but: write(`C:\` ~ (long path) ~ `con`) will succeed. This is just one issue I've noticed... there's probably more lurking. Also, according to the internet: write(chainPath(shortDirectory, "A "), "Win32 API strips trailing space"); readText(chainPath(shortDirectory, "A")); // Win32 API strips trailing space But: write(chainPath(longDirectory, "A "), "Win32 API strips trailing space"); readText(chainPath(longDirectory, "A")); // File not found write(chainPath(shortDirectory, "A.")); // fails write(chainPath(longDirectory, "A.")); // succeeds This is why I think the whole idea is bankrupt. This is why we should use the exact same behavior in all cases. Always use `\\?\` or never use it. Since Windows path handling is weird by default, I'd prefer always using `\\?\`. It's overhead, but not a huge amount of additional overhead compared to filesystem manipulation.
Re: phobo's std.file is completely broke!
On Thursday, 20 September 2018 at 03:15:20 UTC, Vladimir Panteleev wrote: When the OS itself fails to properly deal with such files, I don't think D has any business in *facilitating* their creation by default. Dear lord Windows is terrible. Can we just deprecate it?
Re: This is why I don't use D.
On Thursday, 20 September 2018 at 02:51:52 UTC, Neia Neutuladh wrote: On Monday, 10 September 2018 at 01:27:20 UTC, Neia Neutuladh wrote: Not on dlang.org anywhere, but I built a crude version of this. Results are available at http://ikeran.org/report/. A quick status update: And source code is available at https://git.ikeran.org/dhasenan/dubautotester Please don't judge me.
Re: dub auto-tester
On Thursday, 20 September 2018 at 04:41:21 UTC, Joakim wrote: Nice, what will it take to get this integrated with the official dub website? I need to: * add JSON output to the auto-tester * get the dub registry to scrape the data (or, optionally, push the data to the registry, but that opens up trust issues that I'd rather not get into) * enable SSL on the report site (and probably get a new domain for it) * alter the dub UI to include the data That's all pretty straightforward. BTW, the gitea self-hosted github-workalike you're using looks nice, too bad it's written in Go. ;) Gitea has the benefit of existing, which is surprisingly important.
Re: This is why I don't use D.
On Thursday, 20 September 2018 at 06:41:54 UTC, drug wrote: Autotester should show build logs because for example `nanogui` package reported as failed although it builds on my machines successfully. The tester is now submodule-aware and I removed builds for packages with a `.gitmodules` file. I'm adding logs only for failed builds. This is an annoying amount of UI work that I might well have messed up horribly.
Re: Rather D1 then D2
On Saturday, 22 September 2018 at 20:34:50 UTC, 0xEAB wrote: On Saturday, 22 September 2018 at 19:41:16 UTC, JN wrote: Some code will break, sure, but it's a mechanical change that should be possible to apply by some tool. Who will run this tool? Who's gonna merge the PRs created with this tool? Compatibility fixes would have been easy in the past in many cases - nevertheless, it needs someone to apply them. Which often did not happen in the past, unfortunately. The demon on my shoulder is telling me to add it to dub. Record the last used compiler in dub.selections.json. Add every incompatibility to dfix. If your project was last built with, say, 2.079.0, then dub will detect the current compiler and run dfix with the necessary upgrades when building the project. And it runs `git reset --hard` before doing any of these checks, or applies them in your project's .dub directory. This is pretty cruddy, but it protects you somewhat from unmaintained projects. Though honestly, having a stable compiler version and recommending that people stick with it for multiple years would also help a lot.
Re: Rather D1 then D2
On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat wrote: AFAIK if you port D1 code the only problem is with immutable(char)[] instead of string, and the only thing to know is that immutable(T) and T implicitely convert to const(T). A lot of D1 code was 32-bit only, so there will be tons of uint instead of size_t. Implicit string concatenation was also a thing. I tried porting Jarrett Billingsley's Croc (aka MiniD) to D2, and that was the most common issue I encountered. A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos... Most of the D1 ecosystem died with dsource.org, yes. D1 code doesn't have a modern Phobos, but it does have Tango available, which might help.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 19:59:42 UTC, Erik van Velzen wrote: Nobody in this thread so far has said they are programming in non-ASCII. I did. https://git.ikeran.org/dhasenan/muzikilo
Re: Mobile is the new PC and AArch64 is the new x64
On Thursday, 20 September 2018 at 05:45:52 UTC, Laurent Tréguier wrote: Why did the iPhone, and after that the smartphone industry as a whole, completely crush the classic cell phones when they have such a poor battery life? Smartphones don't have everything previous phones had. The pros simply outweighed the cons. The iPhone became a status symbol very quickly. That drove adoption much better than mere features could.
Updating D beyond Unicode 2.0
D's currently accepted identifier characters are based on Unicode 2.0: * ASCII range values are handled specially. * Letters and combining marks from Unicode 2.0 are accepted. * Numbers outside the ASCII range are accepted. * Eight random punctuation marks are accepted. This follows the C99 standard. Many languages use the Unicode standard explicitly: C#, Go, Java, Python, ECMAScript, just to name a few. A small number of languages reject non-ASCII characters: Dart, Perl. Some languages are weirdly generous: Swift and C11 allow everything outside the Basic Multilingual Plane. I'd like to update that so that D accepts something as a valid identifier character if it's a letter or combining mark or modifier symbol that's present in Unicode 11, or a non-ASCII number. This allows the 146 most popular writing systems and a lot more characters from those writing systems. This *would* reject those eight random punctuation marks, so I'll keep them in as legacy characters. It would mean we don't have to reference the C99 standard when enumerating the allowed characters; we just have to refer to the Unicode standard, which we already need to talk about in the lexical part of the spec. It might also make the lexer a tiny bit faster; it reduces the number of valid-ident-char segments to search from 245 to 134. On the other hand, it will change the ident char ranges from wchar to dchar, which means the table takes up marginally more memory. And, of course, it lets you write programs entirely in Linear B, and that's a marketing ploy not to be missed. I've got this coded up and can submit a PR, but I thought I'd get feedback here first. Does anyone see any horrible potential problems here? Or is there an interestingly better option? Does this need a DIP?
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 21:12:13 UTC, Walter Bright wrote: D supports Unicode in identifiers because C and C++ do, and we want to be able to interoperate with them. Extending Unicode identifier support off into other directions, especially ones that break such interoperability, is just doing a disservice to users. Okay, that's why you previously selected C99 as the standard for what characters to allow. Do you want to update to match C11? It's been out for the better part of a decade, after all.
Re: Updating D beyond Unicode 2.0
On Monday, 24 September 2018 at 01:39:43 UTC, Walter Bright wrote: On 9/23/2018 3:23 PM, Neia Neutuladh wrote: Okay, that's why you previously selected C99 as the standard for what characters to allow. Do you want to update to match C11? It's been out for the better part of a decade, after all. I wasn't aware it changed in C11. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf page 522 (PDF numbering) or 504 (internal numbering). Outside the BMP, almost everything is allowed, including many things that are not currently mapped to any Unicode value. Within the BMP, a heck of a lot of stuff is allowed, including a lot that D doesn't currently allow. GCC hasn't even updated to the C99 standard here, as far as I can tell, but clang-5.0 is up to date.
Re: Why the hell do exceptions give error in the library rather than the user code?
On Friday, 14 September 2018 at 16:43:04 UTC, Josphe Brigmo wrote: It is because you are throwing inside your code. When the throw is from the library, it gives something like this: std.exception.ErrnoException@std/stdio.d(430): Cannot open file `/doesntexist' in mode `w' (Permission denied) /usr/include/dmd/phobos/std/exception.d:515 @safe void std.exception.bailOut!(std.exception.ErrnoException).bailOut(immutable(char)[], ulong, scope const(char)[]) [0x37130b11] ??:? @safe shared(core.stdc.stdio._IO_FILE)* std.exception.enforce!(std.exception.ErrnoException).enforce!(shared(core.stdc.stdio._IO_FILE)*).enforce(shared(core.stdc.stdio._IO_FILE)*, lazy const(char)[], immutable(char)[], ulong) [0x3713ed76] ??:? ref @safe std.stdio.File std.stdio.File.__ctor(immutable(char)[], scope const(char)[]) [0x371345cc] scratch.d:7 void scratch.doThrow() [0x371307db] scratch.d:14 _Dmain [0x37130838] You're on Windows, by the look of it. Windows ships debug symbols in separate files. Do you have the debug symbols (*.pdb files) somewhere accessible? Did you at least compile your own code with -g to generate debug symbols for it?
Re: Why the hell do exceptions give error in the library rather than the user code?
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is pointing
to code in a library which tells me absolutely nothing about
where the error occurs in the in the user code(which is what
matters).
It's what matters when the exception is caused by a bug in user
code. It's what matters when the exception is caused by something
environmental and the operation was a narrow, focused operation
directed by user code.
If you have a bug caused by something in the depths of a complex
library, the full stacktrace matters.
Surely the call stack can be unrolled to find code that exists
in the user code? Or at least display several lines like a
trace stack.
They do, I thought? Let me test quickly:
---
void doThrow()
{
throw new Exception("here!");
}
void main()
{
try
doThrow;
catch (Exception e)
writeln(e);
}
---
That prints something like:
object.Exception@scratch.d(7): here!
scratch.d:7 void scratch.doThrow() [0x9d8acd53]
scratch.d:14 _Dmain [0x9d8acd68]
That's a stacktrace.
And if I don't catch the exception, the runtime still gives me a
stacktrace.
You do need to include debug symbols to get filenames and line
numbers; just compile with -g.
Re: Proposal: __not(keyword)
On Friday, 14 September 2018 at 18:06:55 UTC, Adam D. Ruppe wrote: Here's the simple idea: __not(anything) just turns off whatever `anything` does in the compiler. From your lips to G*d's ears.
Re: dmd as a library for scripting/JIT?
On Friday, 14 September 2018 at 16:02:36 UTC, dennis luehring wrote: i've got user defined flow charts in my C++ application that calling C/C++ Code - could be possible to embedd dmd as a library, generate D code out of my flow charts and execute the "compiled" code directly without doing file io or dmd.exe runs to create dlls that i hot reload? You could potentially embed LDC and LLVM as a library to do that. I don't think it's set up to emit LLVM IR in-memory at the moment, though.
Re: Proposal: __not(keyword)
On Friday, 14 September 2018 at 18:13:49 UTC, Eugene Wissner
wrote:
Makes the code unreadable. You have to count all attributes in
the file, then negate them. Nobody should write like this and
therefore it is good, that there isn't something like __not.
For @nogc, pure and so forth there were imho a better proposal
with a boolean value:
@gc(true), @gc(false), pure(true), pure(false) etc. It is also
consistent with the existing UDA syntax.
The two proposals are extremely similar in effect. Under Adam D
Ruppe's proposal, I could write:
__not(@nogc) void foo() {}
Here, @nogc wasn't set, so I didn't need to specify any
attributes. If @nogc: had been specified a thousand times just
above this function, __not(@nogc) would still make `foo` be
not-@nogc.
Identically, under your proposal, I could write:
@gc(true) void foo() {}
If this is the entire file, the annotation has no effect. If
@gc(false) had been specified a thousand times just above this
function, the annotation would still make `foo` be not-@nogc.
There's no counting of attributes to negate. You just negate
everything that doesn't apply to this function.
Re: More fun with autodecoding
On Saturday, 15 September 2018 at 15:31:00 UTC, Steven Schveighoffer wrote: The problem I had was that it wasn't clear to me which constraint was failing. My bias brought me to "it must be autodecoding again!". But objectively, I should have examined all the constraints to see what was wrong. All C++ concepts seem to do (haven't used them) is help identify easier which requirements are failing. They also make it so your automated documentation can post a link to something that describes the type in more cases. std.algorithm would still be relatively horked, but a lot of functions could be declared as yielding, for instance, ForwardRange!(ElementType!(TRange)). We can fix all these problems by simply identifying the constraint clauses that fail. By color coding the error message identifying which ones are true and which are false, we can pinpoint the error without changing the language. I wish. I had a look at std.algorithm.searching.canFind as the first thing I thought to check. Its constraints are of the form: bool canFind(Range)(Range haystack) if (is(typeof(find!pred(haystack The compiler can helpfully point out that the specific constraint that failed was is(...), which does absolutely no good in trying to track down the problem.
Re: phobo's std.file is completely broke!
On Friday, 14 September 2018 at 19:42:39 UTC, Josphe Brigmo wrote:
It's a bug, but how the hell can I reproduce examples when it
depends on the file system?
Something like this (though I don't know much about Windows, so
this might be wrong):
auto path = getcwd;
auto dir = `0123456789abcdef`;
foreach (i; 0..20)
{
path = buildPath(path, dir);
}
system("mkdir " ~ path);
dirEntries(path, SpanMode.shallow);
And describe what filesystem you're using (presumably NTFS), what
OS and version, 64-bit vs 32-bit, etc.
Re: extern(C++, ns) is wrong
On Saturday, 15 September 2018 at 00:07:44 UTC, Danni Coy wrote: So extern(C++,"ns") replaces the existing syntax It would be in addition, at least at first. The current syntax might be deprecated. and then improve D's general ability to hand functioning hijacking other functions would be the best solution D already has tools for this. and Walters modelling of namespaces is fixing the problem in the wrong place? The current solution solves the very uncommon problem of having two different namespaces in the same file, containing symbols with the same names (or, if functions, with common overloads), where the person writing the bindings needs to keep a one-to-one correspondence between C++ headers and D files, and they don't want to introduce any meaningless structs or templates. Specifically, Walter wants this to compile: module whatever; extern(C++, foo) void doStuff(); extern(C++, bar) void doStuff(); And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like: import core.stdcpp.sstream; import core.stdcpp.vector; core.stdcpp.vector.std.vector v;
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 10:25:30 UTC, Dave Jones wrote: Because for about £300 you can get an intel NUC system with 120GB SSD, which is more powerful and more upgradeable than your £700 mobile device. And some people still want that. For the typical person, it's more likely that they'll get a laptop and replace the whole thing at once instead of upgrading. And a new rise of convergence devices would reduce laptop ownership. Better network connectivity and cloud-based gaming would erode another segment of powerful personal computers. That could also impact things like content editing -- Adobe Creative Cloud might actually be entirely cloud-based eventually. Which is a mild improvement in that you wouldn't need a good computer to run Premiere Pro, but a large problem for actually being able to access your data and products you've purchased. It angers both the EFF and digital archivists. Anyway, it's at least moderately plausible that, thirty years from now, desktop computers will be considered specialized gear.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: Not sure why that matters if you agree with Kay that HTML is an abortion? :) I actually think it's great that mobile is killing off the web, as the Comscore usage stats I linked earlier show. HTML is a somewhat open standard. I'm more happy with HTML and Javascript, as ugly as they are and as dominated by Google and Microsoft as they are, than having to target private companies' frameworks.
Re: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Sunday, 16 September 2018 at 17:33:27 UTC, Steven Schveighoffer wrote: As precedent, we do have -transition=intpromote, which disables the requirement for casting smaller integers to int first. And -dip1000. Maybe it would be nice to have a generic -future=[changeid] flag. I'd like it if these features could be implemented orthogonally enough that we could opt in on a per-module basis and have the same compiler compatible with a much wider range of code. That would be a fair bit of work. Hm... another option is to have a switch identify "useless" casts once the deprecation period is over. Or add it into dfix. Adding it to dfix would be nice, but dfix isn't official or distributed with dmd by default. Also, dfix uses libdparse internally, which is insufficient for handling this type of analysis. libdparse parses code, but this requires figuring out which overloads would be called.
Re: filtered imports
On Thursday, 13 September 2018 at 11:58:40 UTC, rikki cattermole
wrote:
import std.stdio;
import std.file;
void chdir(R)(R path) {
writeln("changing dir to ", path);
std.file.chdir(path);
}
And if you don't want to write long qualified import names, just
rename it:
import sf = std.file;
sf.chdir("foo");
chdir("foo");
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 18 September 2018 at 07:53:31 UTC, Joakim wrote: On Monday, 17 September 2018 at 22:27:41 UTC, Neia Neutuladh wrote: On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: Not sure why that matters if you agree with Kay that HTML is an abortion? :) I actually think it's great that mobile is killing off the web, as the Comscore usage stats I linked earlier show. HTML is a somewhat open standard. I'm more happy with HTML and Javascript, as ugly as they are and as dominated by Google and Microsoft as they are, than having to target private companies' frameworks. So you'd rather target an incredibly badly designed open standard than a mostly open source "private company's" framework that's certainly not great, but much better? It's no contest for me, give me the latter any day. And then of course, there's always cross-platform OSS toolkits like Flutter or DlangUI. Thinking about it a bit more, the openness of the platform is more important. Android and iOS are effectively closed platforms. You *can* sideload apps, but it's rare to find someone willing to do so. If you're not on the app stores, your app isn't going to get a thousandth as much traction. Windows, on the other hand, has long been an open platform; you can develop for it and publish your programs and Microsoft won't get in the way. So an open source cross-platform toolkit controlled by a single entity isn't bad. I use GTK+ a lot, for instance. But the web and HTML is a better situation than Android and iOS and their toolkits.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:23:53 UTC, Joakim wrote: I agree with a lot of what you say here, but I'm not sure what you mean by "first class support for mobile." What exactly do you believe D needs to reach that level? Natural-feeling bindings to platform libraries that are not incredibly slow and that are well-maintained. What does it matter that you can run a webserver from your phone if you can't write a "hello world" GUI program, set an alarm, or enqueue a download?
Re: D outperformed by C++, what am I doing wrong?
On Sunday, 13 August 2017 at 06:09:39 UTC, amfvcg wrote:
Hi all,
I'm solving below task:
Well, for one thing, you are preallocating in C++ code but not in
D.
On my machine, your version of the code completes in 3.175
seconds. Changing it a little reduces it to 0.420s:
T[] result = new T[input.length];
size_t o = 0;
for (uint i; i < input.length; i=min(i+range, input.length))
{
result[o] = sum(input[i..min(i+range, input.length)]);
o++;
}
return result[0..o];
You can also use Appender from std.array.
Re: Visual Studio Code code-d serve-d beta release
On Saturday, 5 August 2017 at 22:43:31 UTC, WebFreak001 wrote: I just released a beta version on the visual studio marketplace that allows you to try out the latest features of serve-d. Awesome! Once I worked around the binary placement issue, this actually gave me completion options, which is better than the previous version ever did for me.
Re: What the hell is wrong with D?
On Tuesday, 19 September 2017 at 17:40:20 UTC, EntangledQuanta wrote: writeln(x + ((_win[0] == '@') ? w/2 : 0)); writeln(x + (_win[0] == '@') ? w/2 : 0); The first returns x + w/2 and the second returns w/2! Yeah, it sucks to have bugs like this crop up. I have enough trouble remembering operator precedence, so I end up using parentheses everywhere and pretending the ternary operator doesn't exist. I also tend to break up complex expressions a lot. It's just safer, and usually clearer.
Re: opEquals code generation
On Tuesday, 19 September 2017 at 13:18:04 UTC, drug wrote:
19.09.2017 15:38, Steven Schveighoffer пишет:
On 9/19/17 8:01 AM, drug wrote:
I iterate over struct members and check against equality
depending on member type. is there more simple/cleaner/better
way to achieve this functionality? Especially without string
mixins?
Why not just use tupleof directly instead of having to find
the member name and using mixins?
-Steve
Hmm, I'm sure I had tried it before and failed, but now I've
managed to do so and it's really simpler
Could be a bit simpler than that, depending on your needs:
bool opEquals(Object other) const nothrow @nogc
{
auto f = cast(typeof(this)) other;
if (f is null) return false;
return this.tupleof == other.tupleof;
}
Re: wstring hex literals
On Wednesday, 20 September 2017 at 15:04:08 UTC, jmh530 wrote: testing_utf16.d(5): Error: Truncated UTF-8 sequence testing_utf16.d(6):while evaluating: static assert((_error_) == (wstring )) Failed: ["dmd", "-unittest", "-v", "-o-", "testing_utf16.d", "-I."] https://dlang.org/spec/lex.html#hex_strings says: The string literals are assembled as UTF-8 char arrays, and the postfix is applied to convert to wchar or dchar as necessary as a final step. This isn't the friendliest thing ever and is contrary to my expectations too. You basically have to encode your string into UTF-8 and then paste the hex of that in. What should work is escape sequences: wstring str = "\u03c0"w;
Re: How to check if path is writable
On Friday, 15 September 2017 at 01:42:02 UTC, Joseph wrote: Is there a cross-platform way in D to check if a path is writable? Try to write to it and see if you get an error.
Re: Tango + D2 + Mac
On Tuesday, 17 October 2017 at 02:52:41 UTC, Fat_Umpalumpa wrote: I am having a lot of trouble trying to install Tango to use with D2 on my mac os Sierra. Is this even possible? Thanks! I take it you're using https://github.com/SiegeLord/Tango-D2 ? I tried it out about a year ago and it worked, but your mileage may vary. For the most part, Phobos and various Dub packages have superseded it. Tango's main benefit was that it was code that was well maintained over the course of several years, and that's no longer true.
Re: Struct List Human
On Sunday, 24 September 2017 at 16:13:30 UTC, dark777 wrote: when you execute and call Name: I type my name: Name: dark777 + [enter] and he does not jump to the next line to get the age This is what I want to know how to solve. Add a `writeln();` after reading input, maybe?
datefmt 1.0.0 released: parse datetimes and also format them
# Sales pitch
If you've ever had to parse datetime input from multiple sources
and everyone's standardized on ISO8601, you might have found out
that that's not quite as standard as you'd wish. This is where
datefmt helps you.
---
import datefmt;
auto expected = SysTime(Date(2010, 1, 1), UTC());
foreach (date; ["2010-01-01", "2010-01-01T00:00:00", "2010-01-01
00:00:00.000Z"])
{
SysTime parsed;
assert(tryParse(date, ISO8601FORMAT, parsed));
assert(expected == parsed);
}
---
# How does datefmt's parsing differ from dateparser?
dateparser is great when you have a date that's in some arbitrary
format and you want to turn it into a sensible date. It's perfect
for manual input.
datefmt is good when you have a restricted set of formats you
need to accept and want to reject everything else -- generally
when a wide range of systems using the same somewhat nebulous
standard emit the stuff you need to parse.
# What about formatting?
datefmt can do formatting too! Most of its formatting options are
taken from strftime, so it should be generally familiar.
And of course you can use predefined formats for RFC1123 and
ISO8601:
auto st = SysTime(DateTime(2010, 4, 12, 15, 30, 00), UTC());
writeln(st.format(ISO8601FORMAT));
// 2010-04-12T15:30:00.00Z
writeln(st.format(RFC1123FORMAT));
// Mon, 12 Apr 2010 15:30:00 Z
# Is anyone using it?
I've been using this in my RSS reader for the past month or two,
during which time it's been exposed to a number of horrible
variants of both RFC1123 and ISO8601.
# How do I get it?
Add "datefmt": "~>1.0.0" to your dub.json and Bob's your uncle!
Or download the single file from
https://raw.githubusercontent.com/dhasenan/datefmt/master/source/datefmt.d and put it in your project.
Licensed under MS-PL (BSD-style permissive license with patent
grant); open an issue at
https://github.com/dhasenan/datefmt/issues if you need a
different license.
Blog post: using dynamic libraries in dub
From the "it's a hacky workaround but it's what we've got" department: how to use dynamic libraries in dub, with GtkD as the example. GtkD takes about 45MB on its own, and that means it can take a fair bit of time to build anything that depends on it -- even if it only uses a handful of symbols. Building it as a dynamic library can shrink compile times significantly. https://blog.ikeran.org/?p=323 An example of this strategy in use: https://git.ikeran.org/dhasenan/resin-browser/src/master/dub.json
Re: datefmt 1.0.0 released: parse datetimes and also format them
On Monday, 18 December 2017 at 09:03:09 UTC, Andrea Fontana wrote: I think you should add some way to translate days/month in other language. That would be great! Unfortunately, it requires a decent locales library.
Re: Seperating class methods in a different module
On Thursday, 7 December 2017 at 02:32:03 UTC, helxi wrote:
1. How can I separate class methods from the declaration block?
And how can I implement them in a separate module?
module a;
class Test
{
import b;
mixin TestMethodImpl!();
}
module b;
template TestMethodImpl()
{
void foo();
}
But this is abnormal for D. We almost invariably put function
bodies inside declarations.
What's your goal with separating the declaration from the
implementation?
If you want people to be *unable* to read method bodies, you can
generate *.di files that only contain declarations. `dmd --help |
grep -i header` or so -- though that keeps in templates and
functions that are candidates for inlining.
If you want to make it easy for someone to look at the API
without wading through function declarations, use ddox to
generate HTML documentation.
Imagine I am making a package called forward_list. Under the
directory forward_list/, I have modules.d that imports
dedicated modules for useful methods like push_back,
insert_after, front, sort, merge etc. Is it an acceptable
practice to declare classes in package.d?
That would be abnormal.
You can look at the layout of std.container by way of comparison
-- one module per container type, one for miscellaneous
utilities, and only documentation in package.d.
Re: package modules and how to generate a shared library plus .di file (I)
On Thursday, 7 December 2017 at 16:39:14 UTC, kdevel wrote: But why do I have to use the prefix "mymod.:" in the library case? If you have an editor open with ten tabs pointing to different files in your source tree, all your imports are uniform -- you don't have to step back and consider where the specific file you're editing is and calculate relative import paths. You always import a given module with the exact same code. If you copy and paste code between two modules and that contains an import statement, it just works. If you decide to move a module to a different package, you need to change its module name, move it on disk, and update the stuff that imports it. You don't have to update every import it does. If you have a source tree like: pierce/ db/ core.d controllers/ feed.d then feed.d can have `import pierce.db.core;` instead of people being confused about how to refer to the parent directory in a relative imports style. The tradeoff is that you have to type sometimes as many as twelve extra characters in a handful of lines of code.
Re: std.conv.to!string refuses to convert a char* to string.
On Saturday, 9 December 2017 at 05:55:21 UTC, Venkat wrote: I am trying out the DJni library (https://github.com/Monnoroch/DJni). For some reason std.conv.to!string doesn't want to convert a char* to a string.The lines below are taken from the log. I see that the last frame is at gc_qalloc. I am not sure why it failed there. Can anybody elaborate on what is going on here ? Thanks in advance. I've got no idea, but can you verify that you can print it with printf? Can you allocate other GC memory? Can you try using fromStringz instead of to!string and see what that does? Just shots in the dark...
Re: Store any callable in an array
On Friday, 4 May 2018 at 15:36:29 UTC, wjoe wrote:
I have a class that I want to be able to register callbacks and
I'd like to be able to register any callable - functions,
delegates, lambdas, anything.
Is there another way to do it besides converting those
toDelegate, which states a bug with @safe functions?
Or better store each type in their own array ?
Cheers!
auto asDelegate(TFunc)(TFunc func) @trusted
{
import std.functional : toDelegate;
return toDelegate(func);
}
The "@trusted" means that you promise this thing is safe, even if
the compiler can't be certain.
Re: Store any callable in an array
On Friday, 4 May 2018 at 19:12:16 UTC, ag0aep6g wrote: If toDelegate isn't (always) @safe, how can you be sure that your wrapper is? If it were @safe, the compiler would accept it. Looking at the code, I believe there are several casts that the compiler can't verify but are used safely. Also, TFunc may have an unsafe destructor. If it's a delegate with an un-@safe destructor (how would that work? a captured context variable?), then it's already not @safe. If it's a function, it doesn't have a destructor. If it's a user-defined type with opCall, that's something to pay attention to, but it's beyond the scope of the original question.
Re: Error: cannot deduce function from argument types
On Saturday, 5 May 2018 at 16:42:12 UTC, Sisor wrote: Error: template std.string.stripRight cannot deduce function from argument types You used http://dpldocs.info/experimental-docs/std.string.stripRight.html This function only takes one argument and strips whitespace. You want http://dpldocs.info/experimental-docs/std.algorithm.mutation.stripRight.1.html This function can take two arguments and strips the second from the first.
Re: is ==
On Saturday, 19 May 2018 at 01:48:38 UTC, Jonathan M Davis wrote: Actually, that runtime function has existed since before TDPL came out in 2010. It even shows the implementation of the free function opEquals (which at the time was in object_.d rather than object.d). I'm not even sure that the error message was added before the free function version of opEquals was. Maybe when that error message was first introduced, it avoided a segfault, but if so, it has been a _long_ time since that was the case. Good catch. I overly trusted git blame. The opEquals(Object, Object) function was added in February 2010, while the error message was added in March 2008. Of course, the most notable case where using == with null is a terrible idea is dynamic arrays, and that's the case where the compiler _doesn't_ complain. Using == with null and arrays is always unclear about the programmer's intent and almost certainly wasn't what the programmer intended. If the programmer cares about null, they should use is. If they care about lengnth, then that's what they should check. Checking null with == is just a huge code smell. I feel like the array == null version is more explicit about not allocating memory. However, I'm paranoid about whether that's going to check the pointer instead, so I mostly use array.length == 0 instead.
Re: is ==
On Saturday, 19 May 2018 at 04:30:24 UTC, Jonathan M Davis wrote: On Saturday, May 19, 2018 03:32:53 Neia Neutuladh via Digitalmars-d-learn wrote: > Of course, the most notable case where using == with null is > a terrible idea is dynamic arrays, and that's the case where > the compiler _doesn't_ complain. Using == with null and > arrays is always unclear about the programmer's intent and > almost certainly wasn't what the programmer intended. If the > programmer cares about null, they should use is. If they > care about lengnth, then that's what they should check. > Checking null with == is just a huge code smell. I feel like the array == null version is more explicit about not allocating memory. However, I'm paranoid about whether that's going to check the pointer instead, so I mostly use array.length == 0 instead. I'm not sure what memory allocations you're worried about. Neither "" nor [] allocates memory "" is syntax for compile-time constants and shouldn't ever allocate. [] is a specific case of [values...]; the general case allocates, but this one case does not. null is not even a compile-time constant; it's a value baked into the language and is guaranteed not to allocate. but regardless, if you're looking to check whether arr.ptr is null, then that's effectively what you get with arr is null I don't think I've ever wanted to distinguish a zero-length slice of an array from a null array. Regardless, if you're checking for null, then is does the job, and if what you care about is whether the array is empty, then that's what arr.length == 0 and arr.empty do. As I already said, I use "array.length == 0". "array.empty" is part of that newfangled range business.
Re: Splitting up large dirty file
On Tuesday, 15 May 2018 at 20:36:21 UTC, Dennis wrote: I have a file with two problems: - It's too big to fit in memory (apparently, I thought 1.5 Gb would fit but I get an out of memory error when using std.file.read) Memory mapping should work. That's in core.sys.posix.sys.mman for Posix systems, and Windows has some equivalent probably. (But nobody uses Windows, right?) - It is dirty (contains invalid Unicode characters, null bytes in the middle of lines) std.algorithm should generally work with sequences of anything, not just strings. So memory map, cast to ubyte[], and deal with it that way? - When you convert chunks to arrays, you have the risk of a split being in the middle of a character with multiple code units It's straightforward to scan for the start of a Unicode character; you just skip past characters where the highest bit is set and the next-highest is not. (0b1100_ through 0b_1110 is the start of a multibyte character; 0b_ through 0b0111_ is a single-byte character.) That said, you seem to only need to split based on a newline character, so you might be able to ignore this entirely, even if you go by chunks.
Re: is ==
On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions wrote: Why does D complain when using == to compare with null? Is there really any technical reason? if one just defines == null to is null then there should be no problem. It seems like a pedantic move by who ever implemented it and I'm hoping there is actually a good technical reason for it. tldr: this error is outdated. In the days of yore, "obj == null" would call "obj.opEquals(null)". Attempting to call a virtual method on a null object is a quick path to a segmentation fault. So "obj == null" would either yield false or crash your program. Except it's worse than that; your opEquals method had to explicitly check for null. So if your class had a custom equality function, "obj == null" was probably going to segfault no matter what. Because of this common source of errors, in DMD 2.012 (2008), we got an error only for the case of comparing with a literal null. (The compiler isn't a mind-reader; it doesn't know whether that variable will be null when that line of code executes.) This still sucked, so in 2015 we got a runtime function to handle object equality: https://github.com/dlang/druntime/blob/dff824eda422b1fcdde5f2fe53120fcd71733aaa/src/object.d#L140 But we haven't removed the error message. It *is* faster to call "foo is null" than "foo == null", but I don't think that's particularly worth a compiler error. The compiler could just convert it to "is null" automatically in that case. One casualty of the current state of affairs is that no object may compare equal to null.
Re: What is the point of nothrow?
On Wednesday, 13 June 2018 at 00:38:55 UTC, Jonathan M Davis wrote: It's possible to write programs that check and handle running out of memory, but most programs don't, and usually, if a program runs out of memory, it can't do anything about it and can't function properly at that point. Simulations that run out of memory are likely unable to recover from OutOfMemoryError. Transactional programs like webservers are likely to run out of memory due to an unusually large request. The idea is that it's a bug in your code if you ever index an array with an index that's out-of-bounds. If there's any risk of indexing incorrectly, then the program needs to check for it, or it's a bug in the program. Most indices are not taken from program input, so treating them as input in the general case wouldn't really make sense The case I find is almost invariably a hard-coded index into input data, like a CSV file that is supposed to have ten columns but only has eight. This is often a bug in my program simply because most exceptions I encounter are bugs in my program. - plus, of course, treating them as program input in the general case would mean using Exceptions, which would then kill nothrow. Which goes back to my point of problems that could be caused by too wide a range of code being Errors.
Re: What is the point of nothrow?
On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
Why do you care about detecting code that can throw an Error?
Errors are supposed to kill the program, not get caught. As
such, why does it matter if it can throw an Error?
Error is currently used for three different things:
* This is a problem that could occur in such a wide range of
circumstances, it would make it difficult to use nothrow.
* This is a problem severe enough that almost every program would
have to abort in these circumstances, so it's reasonable to abort
every program here, and damn the few that could handle this type
of problem.
* This is a problem that someone thinks you might not want to
catch when you write `catch (Exception)`, even if it can't be
thrown from many places and it wouldn't kill most programs.
As an example of the former: I have a service that uses
length-prefixed messages on raw sockets. Someone tries to connect
to this service with curl. The length of the message is read as
0x4854_5450_2131_2E31 -- ASCII "HTTP/1.1" as an unsigned long.
(Or we read a 32-bit length, but we're running on a system with
128MB of RAM and overcommit turned off.)
The program might be in an invalid state if this allocation
fails. It might not. This depends entirely on how it was written.
The runtime is in a valid state. But the exception is
OutOfRangeError, which inherits from Error.
Similarly, RangeError. There's little conceptual difference
between `try {} catch (RangeError) break` and `if (i >= length)
break`. But forbidding dynamic array indexing in nothrow code
would be rather extreme.
On the other hand, a Unicode decoding error is a
UnicodeException, not a UnicodeError. I guess whoever wrote that
thought invalid Unicode data was sufficiently more common than
invalid values in length-prefixed data formats to produce a
difference in kind. This isn't obviously wrong, but it does look
like something that could use justification.
Re: scope(success) lowered to try-catch ?
On Sunday, 17 June 2018 at 10:58:29 UTC, Cauterite wrote:
Is there a reason scope(success) needs to set up for exception
handling?
Or is this a bug / potential enhancement ?
If you had no exception handling in place, you'd need to
duplicate code in the output. For instance:
void foo()
{
scope(success) writeln("success!");
if (a) return;
if (b) return;
throw new Exception;
}
This would have to be lowered to:
void foo()
{
if (a) { writeln("success!"); return; }
if (b) { writeln("success!"); return; }
throw new Exception;
writeln("success!"); // maybe omitted with flow analysis
}
Now imagine there were 20 places you return from the function
early. Now imagine this is in a loop body, where you can leave it
via goto, break, continue, return, or end-of-block. And wrapped
in several if statements.
You generate smaller code with the exception handling system. The
compiler only has to pay attention to scope guards in the code
that handles it directly, instead of at every flow control
statement. Add to that the fact that -betterC is pretty recent
and scope guards are more than ten years old, and you get this
hole in the compiler.
Re: How do I break from loop when using parallel()?
On Monday, 28 May 2018 at 21:04:21 UTC, Dr.No wrote:
import std.parallelism : parallel;
foreach(t; parallel(arr))
{
if(!doSomething(t)) {
return false;
}
}
It reuturns the run time error:
std.parallelism.ParallelForeachError@(0): Cannot break from a
parallel foreach loop using break, return, labeled
break/continue or goto statements.
What's the proper way to break from loop?
By the time you try to break out of the loop, you've already
executed the loop body for later elements in the collection. So
if you could do that, it would give the wrong impression.
The loop body executes on several threads at once. The `return
false` statement might be executing on a different thread, and
`return` only returns on the same thread.
If you want to do this sort of thing (exit on first error, for
instance), you can manually use TaskPool, schedule tasks on it,
and use an atomic variable to exit early on each task if
necessary.
Re: convert string to wchar[]
On Saturday, 26 May 2018 at 17:12:38 UTC, Dr.No wrote:
What's D's way to do that? I need it to be mutable array of
wchar because a Windows function requires that.
Alternative to go down to using pointers, which would be
something like:
wchar[] w = new wchar[s.length];
memcpy(w.ptr, s.ptr, s.length);
std.conv.to has you covered for quite a lot of conversions:
import std.conv;
import std.stdio;
void main()
{
string s = "hello world";
wchar[] mutableUtf16 = s.to!(wchar[]);
mutableUtf16[0] = '☃';
// prints ☃ello world
writeln(mutableUtf16);
}
Re: Remove closure allocation
On Saturday, 26 May 2018 at 15:00:40 UTC, Malte wrote: This compiles with DMD, however it returns random numbers instead of the value I passed in. Looks like a bug to me. Should that work or is there any other pattern I could use for that? Filed as https://issues.dlang.org/show_bug.cgi?id=18910 As for the larger issue, you have to store `q` somewhere. The compiler could store it on the stack, but the compiler would have to do a lot of work to prove that that's safe -- that the return value from `arr.map` doesn't escape the current function, that `map` doesn't save the thing you passed to it anywhere, that sort of thing. And that sort of analysis is flaky. It's a recipe for code that compiles on one version of a compiler and not the next, a lot of bug reports that are hard to track down, that sort of thing. And it means that it has to assume the worst for functions that it doesn't have the source for -- when you pass a delegate, when you call an extern(D) function, when you call a virtual method. So the compiler does the safe thing, and it has the GC allocate a bit of memory to hold `q`. The way around that is the `scope` keyword. The compiler can do that complex analysis one function at a time; that's sufficiently simple. So if you wrote a `map` function, you could define it as taking a `scope U delegate(T)` and the compiler wouldn't need to use the GC there. That obviously adds restrictions on how you can write that function.
Re: determining if array element is null
On Saturday, 2 June 2018 at 18:10:38 UTC, eastanon wrote:
Does D array implementation support an array of null values?
int a[4] = null;
But I ran into a type error while checking if a[i] is null
foreach(i; 0..3){
if(i == null){
writeln("it is null");
}
}
}
How do you set fixed size array of null values and check if
they are null?
There are several problems with your code.
1. `int a[4]` should be `int[4] a`. You probably see a warning
about using the C-style array syntax.
2. `int[4] a = null` treats the initialization as a copy from an
array whose value is null. If you run just that line of code, it
will produce an error at runtime: "object.Error@(0): Array
lengths don't match for copy: 0 != 4"
If you want to initialize every member of an array with a value,
you write it as:
int[4] a;
a[] = 5;
3. `foreach (i; 0..3)` will iterate through a range of integers:
0, 1, and 2. You haven't touched your array.
4. `i == null` is trying to compare an integer, which can never
be null, to null. You either want to use std.typecons.Nullable
(if you just want integers-that-might-be-null) or an array of
pointers to integers (if you want reference semantics).
5. Usually, you want to use `i is null` instead of `i == null`.
Re: how to define infix function
On Saturday, 2 June 2018 at 21:44:39 UTC, greatsam4sure wrote:
Sorry for the typo
is it possible to define infix function in D
3.min(5)// 3: where min is a function, works in D
3 min 5 // does not work.
thanks in advance
This is a horrible abuse of D's operator overloading discovered
by FeepingCreature in the distant past.
You have to delimit your custom infix operator with slashes; you
can't make `3 min 5` work, but you can make `3 /min/ 5` work.
Observe:
struct Min
{
MinIntermediate!T opBinaryRight(string op, T)(T value) if (op
== "/")
{
return MinIntermediate!T(value);
}
}
struct MinIntermediate(T)
{
T value;
T opBinary(string op, T)(T value2) if (op == "/")
{
if (value < value2) return value;
return value2;
}
}
Min min;
void main()
{
writeln(1 /min/ 2);
}
Re: Blog post: using dynamic libraries in dub
On Monday, 25 December 2017 at 08:57:09 UTC, Jacob Carlborg wrote: If I knew exactly what would need to be done I would most likely have done it already :). Perhaps Martin that implemented the support on Linux or David that, I think, implemented it for LDC on macOS would be better suited for such a bugzilla issue. If you know that it doesn't work, please file an issue; a bug that just says "this doesn't work" is more valuable than its absence. If you have a test case, that is valuable; "what would need to be done" is to make the test case work. If you know that it works with LDC, that is also valuable; "what would need to be done" is to port over LDC's fixes. I haven't used a Mac since 2012 (an experience that I am anxious to avoid repeating), so I don't even know whether TLS works with dynamic libraries on OSX. I can't test fixes. All I could do is report that there's a rumor.
Re: Blog post: using dynamic libraries in dub
On Tuesday, 19 December 2017 at 21:38:40 UTC, Mike Wey wrote: And for GtkD, that is why it would make sense to relay on the packages supplied by your distribution. And just list "gtkd-3" in the "libs" section. Avoiding the need for the workaround to build a shared version. That would be awesome. I'm not able to access the d-apt repository at the moment and Ubuntu 16.04 doesn't seem to have gtkd in the repositories. So for the near future, at least, I'll continue using this cruddy workaround.
Re: copy only reference rather duplicate a string in appender!string
On Tuesday, 26 December 2017 at 15:37:12 UTC, Marc wrote: I do build a string by coping large parts of diffrent buffers, all those buffers live after the functional call, so rather than duplicate those string I'd like to copy only references to those parts rather duplicate every string. I combined appender!string, assumeUnique() and array slices. Something like this: This depends on whether you have several variables as buffers or an array of buffers. With several variables: http://dpldocs.info/experimental-docs/std.range.chain.html With an array, or something else iterable: http://dpldocs.info/experimental-docs/std.algorithm.iteration.joiner.2.html So you can use: chain(buf1, buf2, buf3); Or: myBuffers = [buf1, buf2, buf3]; joiner(myBuffers); That produces something string-like. (A rope, but with a poor API.) You can iterate through it as a string, you can output it to a file, etc. You can't pass it to something that expects a string specifically; for instance, you can't return that from `MyClass.toString()`.
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote: Even calling GC.collect directly did not guarantee the DB handle was closed at the right time. This may have been a bug in my code that left dangling references to it, or perhaps the array of Database handles was still scanned through by the GC even though the only remaining array slice has a shorter length. Whatever the reason was, it left me with the very unpleasant prospect of silently accumulating file descriptor leaks. Last I checked, the GC doesn't understand arrays. It only understands "segment of memory that might contain pointers" and "segment of memory that doesn't contain pointers". You might have gotten better results if you had nulled out the reference in the array. Of course, that relies on not having any remaining references on the stack or in registers, neither of which is easy to guarantee.
Re: Dub project has both .sdl and .json files. Is this normal or did I do something wrong?
On Friday, 3 August 2018 at 19:41:32 UTC, Bastiaan Veelo wrote: But if you commit it, and a compiler deprecation causes a dependency in that pinned version to fail to compile, then your app won't compile either, even though your code itself does not suffer from the deprecation and even though a newer release of the dependency is available that solves the deprecations. This means that, if your app is on code.dlang.org, people won't be able to dub fetch && dub run. This is also true if the dependency gets a major version bump and then gets updated for a breaking compiler change. If the dependency range is broad enough, you can `dub upgrade && dub run`. What advantages does committing dub.selections.json have that outweigh this disadvantage? Dependencies don't always follow semantic versioning. For instance, a binding for a C library that is actively developed might reasonably follow the bound library's versioning. Or the maintainer might make a mistake and commit a breaking change without bumping to a new major version. This is why my top-level projects these days have specific versions of dependencies rather than the more commonly used ranges. I'm only going to test against those specific versions, so why should I claim that my application can use future versions? It would be OK if dub.selections.json would also pin the compiler version and there were a standard way to select that version (like dvm, but without its shortcomings). That would be good. If I were less lazy, I could add that to dub. It already manages packages; the compiler is just a slightly different dependency.
Re: Are properties mature enough?
On Sunday, 19 August 2018 at 18:32:17 UTC, QueenSvetlana wrote:
In the D Style Guide, it says:
Properties
https://dlang.org/dstyle.html#properties
Functions should be property functions whenever appropriate. In
particular, getters and setters should generally be avoided in
favor of property functions. And in general, whereas functions
should be verbs, properties should be nouns, just like if they
were member variables. Getter properties should not alter state.
In the Properties function section, it says:
https://dlang.org/spec/function.html#property-functions
WARNING: The definition and usefulness of property functions is
being reviewed, and the implementation is currently incomplete.
Using property functions is not recommended until the
definition is more certain and implementation more mature.
So which is it?
The `@property` annotation might not remain in the language.
However, the property call syntax for functions will remain.
So you can write:
---
struct Random
{
private int value;
int next() { value++; return value; }
void seed(int value) { this.value = value; }
}
Random r;
r.seed = 21;
writeln(r.next);
---
That's going to work forever.
You *could* add @property to the next and seed functions. That
forces people to use them as fields. However, there's some
discussion about how that's going to be handled in the future. So
you might want to leave it off.
Re: [OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections
On Sunday, 9 September 2018 at 09:34:31 UTC, Nick Sabalausky (Abscissa) wrote: 1. As most United States citizens are implicitly aware (though the government assumes NO responsibility to ensure citizens are aware of this), to vote in a United States of America election and have the vote legally *count*, a United States citizen MUST vote on the exact day of elections, from the exact location determined to be the correct voting location for said citizen. In Ohio, early voting begins 10 October: https://www.sos.state.oh.us/elections/voters/voting-schedule/ Some areas have vote-by-mail as the default. This increases turnout for non-Presidential elections from abysmal to merely shameful. In these areas, you don't need to go to a specific location (though there are ballot drop-off locations if you don't want to trust your ballot in the mail).
Re: Better diagnostics for null classes dereferencing
On Tuesday, 10 July 2018 at 22:53:25 UTC, kdevel wrote:
extern (C) __gshared bool rt_trapExceptions;
static this ()
{
rt_trapExceptions = false;
}
This will catch exceptions raised in main and in static
constructors that run after this one. However, if you put that
code in the module that includes main(), it's probably going to
be the last static constructor run. That means it doesn't impact
other static constructors.
The only fix for that is putting this code in its own module that
you add as the first import in every module. And if you depend on
any library with a static constructor anywhere inside, you have
to modify that library.
But exceptions can be thrown before any static constructor is
run. The function that calls static constructors might detect a
cycle straight off, for instance.
That's why the This Week In D post injected it into the C main
function.
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole wrote: Here is a question (that I don't think has been asked) why not @copy? It's not wrong to call this an implicit constructor since it's called implicitly. It also means that, if we get implicit constructors in general, we can keep the same syntax and annotations, and it will be consistent. Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other); That would be possible, but it would be inconsistent with super constructors in general.
Re: static array of pointers to dynamic arrays of ints problem...
On Sunday, 22 April 2018 at 06:00:15 UTC, WhatMeForget wrote:
foreach(i, elem; a)
{
int[] temp = new int[](5);
..
a[i] =
}
You're taking the address of a local variable and persisting it
beyond the variable's scope. This is not safe in general;
compilers regularly reuse spaces on the stack. DMD specifically
tends to do this reliably with foreach loop bodies.
You see the same thing in C:
#include
int main(int argc, char** argv)
{
int* p[2];
for (int i = 0; i < 2; i++)
{
int f = i;
p[i] =
}
printf("p[0] = %x, *p[0] = %d\n", p[0], *p[0]);
printf("p[1] = %x, *p[1] = %d\n", p[1], *p[1]);
return 0;
}
Which prints something like:
p[0] = d9b69428, *p[0] = 1
p[1] = d9b69428, *p[1] = 1
Re: Beta 2.082.0
On Wednesday, 17 October 2018 at 14:02:20 UTC, Jesse Phillips wrote: Wait, why does each get a special bailout? Doesn't until full that role? `until` is lazy. We could have `doUntil` instead, which would be eager and would return a boolean indicating whether to continue. We could all write `someRange.until!condition.each!func`. That's going to be clearer sometimes and less clear other times. So now we have options.
Re: how to make '==' safe for classes?
On Sun, 28 Oct 2018 18:00:06 +, Stanislav Blinov wrote: > On Sunday, 28 October 2018 at 12:38:12 UTC, ikod wrote: > >> and object.opEquals(a,b) do not inherits safety from class C >> properties, and also I can't override it. > > Yep. Since Object is the base class and it defines opEquals as: > ``` > bool opEquals(Object); > ``` > > the compiler rewrites `a == b` as > `(cast(Object)a).opEquals(cast(Object)ob)`, i.e. it inserts a @system > call into your code. More pedantically, it rewrites it as: (a is b) || (a !is null && (cast(Object)a).opEquals(cast(Object)b)) An object might not be equal to itself via opEquals, but it will always compare equal to itself with ==.
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Mon, 29 Oct 2018 03:43:49 +, Mike Parker wrote: > Congratulations are in order for Iain Buclaw. His efforts have been > rewarded in a big way. Last Friday, he got the greenlight to move > forward with submitting his changes into GCC: Awesome! What frontend version is this, out of curiosity?
Dealing with raw types as attributes
The spec says that a user-defined attribute must be an expression, but DMD
accepts a wide range of things as UDAs:
struct Foo { string name = "unknown"; }
@Foo int bar;
`bar` has the *type* Foo as an attribute. It's not an *instance* of Foo.
So if I try to look at the UDAs:
static foreach (uda; __traits(getAttributes, bar))
{
static if (is(typeof(uda) == Foo))
{
pragma(msg, "bar is @Foo");
}
}
That just doesn't work; typeof(Foo) isn't anything, so is(typeof(Foo) ==
Foo) is false.
I can change my code to read `static if (is(uda == Foo))`. But that
obviously fails:
@Foo("customName") int bar2;
What do you do to handle this?
My current workaround is to make the attribute into a struct instance and
use opCall in lieu of constructors:
struct _Foo
{
string name;
_Foo opCall(string name)
{
_Foo f;
f.name = name;
return f;
}
}
enum _Foo Foo = _Foo.init;
Now I can use `static if (is(typeof(uda) == _Foo))` and it always works.
But are there better options? Any obvious flaws?
Re: New Initiative for Donations
On Fri, 26 Oct 2018 06:19:29 +, Joakim wrote: > On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote: >> On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote: >>> As with D, sometimes the new _is_ better, so perhaps you shouldn't >>> assume old is better either. >> >> There's no assuming going on. Cryptocurrencies are worse than credit >> cards for everything that normal people care about, > > Such as? I already noted that they're easier and cheaper, you simply > flatly state that "normal people" find them worse. In most countries where people are going to donate to D, the vast majority of people have access to a credit card. >> If for some reason cryptocurrencies become popular and sufficiently >> stable to be used as currency, I have no doubt that existing credit >> card companies will start offering automatic currency exchange, so you >> can have an account in USD and pay a vendor who accepts only Ethereum, >> or vice versa. As such, accepting credit card payments is good enough. > > I don't know what we'd be waiting for, the tokens I mentioned are all > worth billions and widely used, particularly by techies: Very few merchants accept any sort of cryptocurrency. I think I've found three. One was through a cryptocurrency forum, and one was Valve announcing that they would stop accepting it. > Why would I wait for antiquated credit-card companies to accept these > tokens? The whole point of these new tokens is to obsolete the credit > card companies. You wouldn't wait. You haven't waited. For you, the benefits are large enough and the downsides small enough that it doesn't make sense to wait. But I'm not you. I would wait because I've lost access to important credentials before and had to send a copy of my government-issued ID to a company to get them to deactivate two-factor authentication. I've had to use password reset mechanisms frequently. I don't trust myself not to lose access to a cryptocurrency private key. And that would destroy currency and lose me my life savings. I would wait because I want a mechanism to dispute transactions. Maybe I authorized that transaction, but the merchant didn't deliver. I would wait because I want an environmentally-friendly system instead of one that uses as much electricity as Afghanistan to process fifteen transactions per second. I would wait because cryptocurrencies have extremely volatile exchange rates, which makes it difficult to set prices or store value in them. I would wait because I can't use cryptocurrency to do anything useful, so I would incur a fee to transfer money into it and another to transfer money out of it. I would wait because I don't trust any cryptocurrency exchanges to stick around like I expect Visa or even a community bank to remain in business, or even not to commit fraud against me. While I might not trust my local bank much, I do trust my government to regulate them and to bail me out should the worst happen. I think my concerns are rather normal. Judging by adoption, there's some set of concerns that's normal.
Re: New Initiative for Donations
On Sat, 27 Oct 2018 10:54:30 +, Joakim wrote: > I see, so you want other taxpayers to bail you out for your mistakes, > interesting. One of the major points of having a government is to create these regulations that make it less likely for individuals to suffer from the actions of other people and organizations. Another major point is to help people in need using the collective efforts of society. Programs like FDIC in the United States exist to serve both of these: it's an extra set of regulations for banks, and compliant banks will be bailed out if circumstances require. If I choose an FDIC bank and the owners run off with my money, I didn't make an avoidable mistake, any more than being mugged in the street is me making a mistake. If you oppose that, you're gunning for an eventual repeat of the Great Depression. >> I think my concerns are rather normal. Judging by adoption, there's >> some set of concerns that's normal. > > Some of them are popularly held, but most are fairly irrational. > > In any case, whether crypto-currencies ever go mainstream is irrelevant > to this thread. They're already fairly popular among techies, from whom > the D foundation is soliciting donations. As such, providing a way to > accept such donations is literally a no-brainer: the work put into > taking them will likely pay for itself many times over. I suspect more techies use zloty than ethereum.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sat, 03 Nov 2018 04:50:52 +, unprotected-entity wrote: > (q1) Why is it, that people who use D, object *so much* to the idea of > allowing (at the choice of the programmer) for a type to have it's own > private state *within* a module (so that its private state is respected > by other code also within that module)? We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them. We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you. > Or you ask it another way: > > (q2)Why must a type within a module *always* have its private state > exposed to other code within the module? (the key word here, being > 'always'). Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list. > (q3) Should a language intentionally set out to prevent a programmer > from making that choice? You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sat, 03 Nov 2018 11:24:06 +, FooledDonor wrote: > And if the validity of a person's reasoning is a function of his way of > expressing them, well ... do not pose to software engineers at least If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people. This is true even if the feature seems obviously good and necessary to one or two people, if those people don't have abnormally large influence over the project.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote: > Can we argue about the problems arising from the potential introduction > of this feature? There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things. The justification for this feature rests on real-world examples of bugs that have been caused by its lack.
