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: Updating D beyond Unicode 2.0
On Friday, 21 September 2018 at 20:25:54 UTC, Walter Bright wrote: When I originally started with D, I thought non-ASCII identifiers with Unicode was a good idea. I've since slowly become less and less enthusiastic about it. First off, D source text simply must (and does) fully support Unicode in comments, characters, and string literals. That's not an issue. 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. Not seeing identifiers in languages you don't program in or can read in is expected. If it's supported it will be used: Japanese Swift: https://speakerdeck.com/codelynx/programming-swift-in-japanese Extending it further will also cause problems for all the tools that work with D object code, like debuggers, disassemblers, linkers, filesystems, etc. Absent a much more compelling rationale for it, I'd say no. More compelling than: "there're 6 billion people in this world who don't speak english?" Allowing people to program in their own language while reducing the cognitive friction for people who want to learn programming in the majority of the world seems like a no-brainer thing to do.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 19:59:42 UTC, Erik van Velzen wrote: If there was a contingent of Japanese or Chinese users doing that then surely they would speak up here or in Bugzilla to advocate for this feature? https://forum.dlang.org/post/piwvbtetcwyxlaloc...@forum.dlang.org
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 23/09/18 04:29, sarn wrote: On Sunday, 23 September 2018 at 00:18:06 UTC, Adam D. Ruppe wrote: I have seen Japanese D code before on twitter, but cannot find it now (surely because the search engines also share this bias). You can find a lot more Japanese D code on this blogging platform: https://qiita.com/tags/dlang Here's the most recent post to save you a click: https://qiita.com/ShigekiKarita/items/9b3aa8f716848278ef62 Comments in Japanese. Identifiers in English. Not advancing your point, I think. Shachar
Re: Updating D beyond Unicode 2.0
On 09/21/2018 04:18 PM, Adam D. Ruppe wrote: > Well, for example, with a Chinese company, they may very well find > forced English identifiers to be an annoyance. Fully aggreed but as far as I know, Turkish companies use English in source code. Turkish alphabet is Latin based where dotted and undotted versions of Latin letters are distinct and produce different meanings. Quick examples: sık: dense (n), squeeze (v), ... sik: penis (n), f*ck (v) [1] şık: one of multiple choices (1), swanky (2) döndür: return dondur: make frozen sök: disassemble, dismantle, ... sok: insert, install, ... şok: shock Hence, non-Unicode is unacceptable in Turkish code unless we reserve programming to English speakers only, which is unacceptable because it would be exclusionary and would produce English identifiers that are frequently amusing. I've seen the latter in code of English learners. :) Ali [1] https://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail
[Issue 19260] extern(C++) `T* const` mangling
https://issues.dlang.org/show_bug.cgi?id=19260
ki...@gmx.net changed:
What|Removed |Added
CC||ki...@gmx.net
--- Comment #1 from ki...@gmx.net ---
Patching the mangle at compile-time like this (MSVC only) might work:
extern(C++) template deallocate(T)
{
void _deallocate(T* ptr, size_t count);
private extern(D) string getMangle()
{
import std.array;
return _deallocate.mangleof.replace("PEAU", "QEAU");
}
pragma(mangle, getMangle())
void deallocate(T* ptr, size_t count);
}
D: https://run.dlang.io/is/q4kF2e
C++: https://godbolt.org/z/GpXfqV
--
Re: Updating D beyond Unicode 2.0
On 09/22/2018 09:27 AM, Neia Neutuladh wrote: > Logographic writing systems. There is one logographic writing system > still in common use, and it's the standard writing system for Chinese > and Japanese. I had the misconception of each Chinese character meaning a word until I read "The Chinese Language, Fact and Fantasy" by John DeFrancis. One thing I learned was that Chinese is not purely logographic. Ali
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: https://codepen.io/andresgalante/pen/jbGqXj It's not like we have a lot of good fonts (I know only one), and even fewer of them are suitable for code, and they can't be realistically expected to do everything, monospace fonts are even often ascii-only.
Re: SerialPort
On Thursday, 20 September 2018 at 10:51:52 UTC, braboar wrote:
I am going to play with serial port read/write, so I fetched
serial-port. After that, I wrote simple program:
auto port_name = "/dev/ttyUSB1";
auto reader = new SerialPort(port_name);
reader.dataBits(DataBits.data8);
reader.stopBits(StopBits.one);
reader.parity(Parity.none);
reader.speed(BaudRate.BR_230400);
string[] income;
reader.read(income);
and the result is
serial.device.TimeoutException
Can anybody give me a guide of using serial port?
And one more question: how to outline code blocks? ''' or ---
can't help me.
here is my code really works:
com is `reader` object in your code.
```
void writeBytes(ubyte[] arr)
{
com.write(arr);
}
void serialThread()
{
ubyte[500] buff;
running = true;
while (running)
{
string str;
size_t readed;
try
{
readed = com.read(buff);
// if (readed > 0) {
//writeln("com port readed " ~
std.conv.to!string(readed));
str = cast(string)(buff[0 .. readed]).idup;
// Don't use writeln for console or string serail
application.
write(str);
// }
}
// must catch for continous reading, otherwize, com
port will block.
catch (TimeoutException e)
{
}
}
}
```
thanks!
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 11:18:42 UTC, Ali Çehreli wrote: Hence, non-Unicode is unacceptable in Turkish code You even contributed to http://code.google.com/p/trileri/source/browse/trunk/tr/yazi.d
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 06:53:21 UTC, Shachar Shemesh wrote: On 23/09/18 04:29, sarn wrote: You can find a lot more Japanese D code on this blogging platform: https://qiita.com/tags/dlang Here's the most recent post to save you a click: https://qiita.com/ShigekiKarita/items/9b3aa8f716848278ef62 Comments in Japanese. Identifiers in English. Not advancing your point, I think. Shachar Well, I knew that when I posted, so I honestly have no idea what point you assumed I was making.
Re: Rather D1 then D2
On Saturday, 22 September 2018 at 13:22:03 UTC, new wrote: On Saturday, 22 September 2018 at 10:53:25 UTC, bauss wrote: On Saturday, 22 September 2018 at 09:42:48 UTC, Jonathan Marler wrote: I'd be interested to hear/read about the features that some developers don't like with D2. I'm going to guess it has to do with all the attributes for functions which you often have to remember is it @attribute or is it just attribute like is it @nogc or is it nogc etc. It's one of the things that probably throws off a lot of new users of D, because they feel like they __have__ to know those although they're often optional and you can live without them completely. They make the language seem bloated. the language is bloated. trying to read the source of D2 makes gives you the feeling of getting eye cancer. so we decided if D at all then it should be D1. Hello, You can have a pretty much "D1" experience if you avoid new features: - @nogc - shared - avoid constness (well except strings), inout - alias bit = bool; // :) - struct postblit - etc.. 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). D2 the language has become longer to learn, but there is a subset that is very much like D1. It's a matter of introducing features as you go, one by one. A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos...
Re: Rather D1 then D2
On Sunday, 23 September 2018 at 13:55:02 UTC, Guillaume Piolat wrote: A lot of things are objectively better like build systems, ecosystems, stability, meta-programming, CTFE, OPTLINK, Phobos... I wouldn't say meta-programming and CTFE are 'objectively' better. It could be argued that such features lengthen compilation time and make it harder to parse D code (thus harder to write tools for it).
Compile-time branching on type size between segregator members during segregator. allocate()
After looking at https://www.youtube.com/watch?v=kaA3HPgowwY and std.experimental.allocator.building_blocks.segregator.Segregator I wonder if Segregator.allocate() is missing an important optimization on calls to someSegregatorInstance.make!T() where the choice of selecting the right segregator member can be done at _compile-time_ instead of run-time because `T.sizeof` is known at compile time. If so, what about adding an optional member to the allocator API, say, void[] allocate(size_t s)() that can realize this idea?
Re: Rather D1 then D2
On Saturday, 22 September 2018 at 19:04:41 UTC, Henrik wrote:
On Saturday, 22 September 2018 at 15:45:09 UTC, Jonathan Marler
wrote:
On Saturday, 22 September 2018 at 15:25:32 UTC, aberba wrote:
[...]
Yeah there's been alot of discussion around it over the years,
which is why I put this together about 4 years ago:
https://wiki.dlang.org/Language_Designs_Explained#Function_attributes
Gosh I've forgotten how long I've been using D.
Interesting article.
"int safe = 0; // This code would break if "safe" was added as
a keyword"
You don't have to turn the @ words to non-@s. You can go the
other way and make attributes consistently use @ as well and
remove them as keywords.
So
pure void f() {} // Deprecated, attributes must start with @
[Issue 14064] Error message about @ attributes incomplete.
https://issues.dlang.org/show_bug.cgi?id=14064 wolframw changed: What|Removed |Added Status|NEW |ASSIGNED CC||wolfr...@protonmail.com Assignee|nob...@puremagic.com|wolfr...@protonmail.com --- Comment #1 from wolframw --- The missing @nogc has already been fixed by https://github.com/dlang/dmd/pull/6084 However, no spell checker exists yet, so I'll make one. --
Re: Jai compiles 80,000 lines of code in under a second
On Sunday, 23 September 2018 at 21:15:17 UTC, FromAnotherPlanet wrote: On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev wrote: On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote: On 9/20/2018 10:11 PM, mate wrote: Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls. Back in the naive olden days, Microsoft released ActiveX, where a web page could load executable objects (!) from the internet and run them in the browser. It quickly became apparent that this was a disaster, as lots of people on the internet aren't to be trusted. CTFE on D doesn't allow making any system calls. This is on purpose. The usual argument against this is that source code distributions already usually include some sort of build or installation script (be it in the form of "configure", or a makefile, or a Visual Studio project), which can already execute arbitrary commands. The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably. Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version. The counter argument is that the compiler is generally not a vector for a computer virus. If I notice I have malware on my computer, I'll think of the websites and the installer scripts I've run recently. I would never expect that some arbitrary code I included in a project would have created a virus and installed it while the compiler built. Sounds like a potential disaster to me. I frequently copy and paste code I don't yet understand all of the time in hopes of understanding it by running it through a compiler. I will personally not ever use Jai. Just to add to this previous comment...just imagine my worries but having to worry about an entire corporation worth of developers potentially doing something stupid and spreading it to everyone else via source control and the Jai compiler...
Re: Jai compiles 80,000 lines of code in under a second
On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev wrote: On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote: On 9/20/2018 10:11 PM, mate wrote: Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls. Back in the naive olden days, Microsoft released ActiveX, where a web page could load executable objects (!) from the internet and run them in the browser. It quickly became apparent that this was a disaster, as lots of people on the internet aren't to be trusted. CTFE on D doesn't allow making any system calls. This is on purpose. The usual argument against this is that source code distributions already usually include some sort of build or installation script (be it in the form of "configure", or a makefile, or a Visual Studio project), which can already execute arbitrary commands. The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably. Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version. The counter argument is that the compiler is generally not a vector for a computer virus. If I notice I have malware on my computer, I'll think of the websites and the installer scripts I've run recently. I would never expect that some arbitrary code I included in a project would have created a virus and installed it while the compiler built. Sounds like a potential disaster to me. I frequently copy and paste code I don't yet understand all of the time in hopes of understanding it by running it through a compiler. I will personally not ever use Jai.
Re: Webassembly TodoMVC
On Saturday, 22 September 2018 at 19:51:48 UTC, Sebastiaan Koppe wrote: On Saturday, 22 September 2018 at 14:54:29 UTC, aberba wrote: Can the SPA code be released as a separate module for WebAssembly web app development? Currently the whole thing is not so developer-friendly, it was just the easiest way for me to get it up and running. Right now I am trying to ditch emscripten in favor of ldc's webassembly target. This will make it possible to publish it as a dub package (ldc only), as well as reduce some of the bloat. The downside is that ditching emscripten means I have to implement things like malloc and free myself. There is some obvious overlap between this and recent efforts by others (I remember D memcpy, and people trying to run it without libc, etc.), so I expect a situation in the future where all these efforts might be combined. Regardless, I don't need much from the C library, just enough to make (de)allocations and parts of the D standard library work. TL;DR I intend to publish it on dub, but it does takes some more time. What do you think of the struct approach compared to a traditional jsx/virtual-dom? As a pro web developer, I think JSX will be the perfect abstraction for maximum adoption. React, being one of the most popular library for developing web applications, is loved by the community. Its the perfect way to model UI components that fits well in my logic. "ReactJS provided the solution that developers were looking for. It uses JSX (a unique syntax that allows HTML quotes as well as HTML tag syntax application for rendering specific subcomponents) This is very helpful in promoting construction of machine-readable codes and at the same time compounding components into a single-time verifiable file. ... ... It allows developers to write their apps within JavaScript. JSX is one of the greatest features that not only makes ReactJS easy but fun too. Developers can easily make a new UI feature and see it appear in real time. It brings HTML directly into your JS. ... ... Components allow developers to break down complex UI. The idea of components is what makes ReactJS unique. Instead of worrying about the entire web app, it makes it possible to break the complex UI/UX development into simpler components. This is crucial in making every component more intuitive." See JSX: https://medium.com/@thinkwik/why-reactjs-is-gaining-so-much-popularity-these-days-c3aa686ec0b3 I'm personally not tied to any framework or library. Only use React/JSX because its solves a real and practical problem for me. Something most web developers agree from the stackoverflow 2017 survey: https://insights.stackoverflow.com/survey/2017
Re: Webassembly TodoMVC
On Sunday, 23 September 2018 at 17:53:32 UTC, Suliman wrote: What do you think of the struct approach compared to a traditional jsx/virtual-dom? jsx is sucks. Look at Vue.js way, if you will able to fo you framework Vue-style it will be perfect! Being a Vue user for three years now, I completely agree. /P
Re: Webassembly TodoMVC
On Sunday, 23 September 2018 at 17:53:32 UTC, Suliman wrote: What do you think of the struct approach compared to a traditional jsx/virtual-dom? jsx is sucks. Look at Vue.js way, if you will able to fo you framework Vue-style it will be perfect! The reason I made this wasm experiment was not to port some js-framework over to D, just to do the same thing but then in D. If I like some js framework out there, I would just use that one. My goal here is to bring something new to the table.
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 08:52:32 UTC, Jonathan M Davis wrote: Honestly, I was horrified to find out that emojis were even in Unicode. It makes no sense whatsover. Emojis are supposed to be sequences of characters that can be interepreted as images. Treating them like Unicode symbols is like treating entire words like Unicode symbols. It's just plain stupid and a clear sign that Unicode has gone completely off the rails (if it was ever on them). Unfortunately, it's the best tool that we have for the job. According to the Unicode website, http://unicode.org/standard/WhatIsUnicode.html, """ Support of Unicode forms the foundation for the representation of languages and symbols in all major operating systems, search engines, browsers, laptops, and smart phones—plus the Internet and World Wide Web (URLs, HTML, XML, CSS, JSON, etc.)""" Note, unicode supports symbols, not just characters. The smiley face symbol predates its ':-)' usage in ascii text, https://www.smithsonianmag.com/arts-culture/who-really-invented-the-smiley-face-2058483/. It's fundamentally a symbol, not a sequence of characters. Therefore it is not unreasonable for it to be encoded with a unicode number. I do agree though, of course, that it would seem bizarre to use an emoji as a D identifier. The early history of computer science is completely dominated by cultures who use latin script based characters, and hence, quiet reasonably, text encoding and its automated visual representation by compute based devices is dominated by the requirements of latin script languages. However, the world keeps turning and, despite DT's best efforts, China et al. look to become dominant. Even if not China, the chances are that eventually a non-latin script based language will become very important. Parochial views like "all open source code should be in ASCII" will look silly. However, until that time D developers have to spend their time where it can be most useful. Hence the condition of whether to apply Neia's patch / ideas or not mainly depends on how much effort the donwstream effort will be (debuggers etc. as Walter pointed out), and how much the gain is. As unicode 2.0 is already supported I would take a guess that the vast majority of people with access to a computer can already enter identifiers in D that are rich enough for them. As Adam said though, it would be a good idea to at least ask!
[Issue 19261] New: Cmdline option to enumerate builtin versions
https://issues.dlang.org/show_bug.cgi?id=19261 Issue ID: 19261 Summary: Cmdline option to enumerate builtin versions Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Tooling needs to perform syntax highlighting. This requires knowledge of the builtin versions specified by the compiler build. Please add a cmdline option to DMD to emit a list of all builtin versions which can be plumbed into editor tooling. --
Re: Updating D beyond Unicode 2.0
On 9/23/2018 9:52 AM, aliak wrote: Not seeing identifiers in languages you don't program in or can read in is expected. On the other hand, I've been programming for 40 years. I've customized my C++ compiler to emit error messages in various languages: https://github.com/DigitalMars/Compiler/blob/master/dm/src/dmc/msgsx.c I've implemented SHIFT-JIS encodings, along with .950 (Chinese) and .949 (Korean) code pages in the C++ compiler. I've worked in Japan writing software for Japanese companies. I've sold compilers internationally for 30 years (mostly to Germany and Japan). I did the tech support, meaning I'd see their code. --- There's a reason why dmd doesn't have international error messages. My experience with it is that international users don't want it. They prefer the english messages. I'm sure if you look hard enough you'll find someone using non-ASCII characters in identifiers. --- When I visited Remedy Games in Finland a few years back, I was surprised that everyone in the company was talking in english. I asked if they were doing that out of courtesy to me. They laughed, and said no, they talked in English because they came from all over the world, and english was the only language they had in common.
Re: Webassembly TodoMVC
What do you think of the struct approach compared to a traditional jsx/virtual-dom? jsx is sucks. Look at Vue.js way, if you will able to fo you framework Vue-style it will be perfect!
Re: Webassembly TodoMVC
On Saturday, 22 September 2018 at 19:51:48 UTC, Sebastiaan Koppe wrote: On Saturday, 22 September 2018 at 14:54:29 UTC, aberba wrote: [...] Currently the whole thing is not so developer-friendly, it was just the easiest way for me to get it up and running. [...] Vladimir mentioned that there's a Musl port to wasm, have you tried it? https://github.com/jfbastien/musl Druntime and ldc support Musl.
Re: Webassembly TodoMVC
On Sunday, 23 September 2018 at 18:36:11 UTC, Joakim wrote: Vladimir mentioned that there's a Musl port to wasm, have you tried it? My knowledge of the intersection of Musl and WASM is that Musl is used as the libc in Emscripten (and, as extension, in Dscripten), and Emscripten/Dscripten can target WASM as well as asm.js / regular ol' JavaScript.
Progress of Project Blizzard
Has there been any progress on Project Blizzard?
Is there some working code available other than the snippets
proposed at Alexandru's talk on DConf 2018?
I'm also curious why the allocation in the following code fails
with exit code -11 with both dmd and ldc on Ubuntu 18.04 x64:
import std.experimental.allocator;
import std.experimental.allocator.building_blocks : Segregator;
import
std.experimental.allocator.building_blocks.ascending_page_allocator;
import
std.experimental.allocator.building_blocks.aligned_block_list;
import std.experimental.allocator.building_blocks.bitmapped_block;
void benchmarkBlizzardSafeAllocator()
{
alias SafeAllocator = Segregator!(16,
AlignedBlockList!(BitmappedBlock!16,
AscendingPageAllocator*,
1 <<
21),
AscendingPageAllocator*);
SafeAllocator allocator;
int* i = allocator.make!int(32); // TODO: this fails with
exit code -11
}
taken directly from the talk.
Is it because I'm using `BitmappedBlock` instead of
`SafeBitmappedBlock`, which I couldn't find in Phobos eventhough
Alexandru's talk assumes it existence in Phobos...
Re: Updating D beyond Unicode 2.0
On 9/22/2018 6:01 PM, Jonathan M Davis wrote: For better or worse, English is the international language of science and engineering, and that includes programming. In the earlier days of D, I put on the web pages a google widget what would automatically translate the page into any language google supported. This was eventually removed (not by me) because nobody wanted it. Nobody (besides me) even noticed it was removed. And the D community is a very international one. Supporting Unicode in identifiers gives users a false sense that it's a good idea to use them. Lots of programming tools don't work well with Unicode. Even Windows doesn't by default - you've got to run "chcp 65001" each time you open a console window. Filesystems don't work reliably with Unicode. Heck, the reason module names should be lower case in D is because mixed case doesn't work reliably across filesystems. 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.
D web site and accessibility
I met a blind programmer at a conference back in the 80's, and had a long talk with her and how she did it. I was amazed. Ever since, I've wanted to ensure products I've worked on were accessible to the blind. It's one thing to follow guidelines, it's another to have someone who relies on a screenreader actually try it out. If anyone here uses a screenreader, or knows someone who does, please give dlang.org a try and let us know about how we can improve their experience with it.
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. I always thought D supported Unicode with the goal of going forward with it while C was stuck with ASCII: http://www.drdobbs.com/cpp/time-for-unicode/228700405 "The D programming language has already driven stakes in the ground, saying it will not support 16 bit processors, processors that don't have 8 bit bytes, and processors with crippled, non-IEEE floating point. Is it time to drive another stake in and say the time for Unicode has come? " Have you changed your mind since?
Re: Updating D beyond Unicode 2.0
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.
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 9/23/2018 6:06 PM, Dennis wrote: Have you changed your mind since? D the language is well suited to the development of Unicode apps. D source code is another matter.
Re: Updating D beyond Unicode 2.0
On 23/09/18 15:38, sarn wrote: On Sunday, 23 September 2018 at 06:53:21 UTC, Shachar Shemesh wrote: On 23/09/18 04:29, sarn wrote: You can find a lot more Japanese D code on this blogging platform: https://qiita.com/tags/dlang Here's the most recent post to save you a click: https://qiita.com/ShigekiKarita/items/9b3aa8f716848278ef62 Comments in Japanese. Identifiers in English. Not advancing your point, I think. Shachar Well, I knew that when I posted, so I honestly have no idea what point you assumed I was making. I don't know what point you were trying to make. That's precisely why I posted. I don't think D currently or ever enforces what type of (legal UTF-8) text you could use in comments or strings. This thread is about what's legal to use in identifiers. The example you brought does not use Unicode in identifiers, and is, therefor, irrelevant to the discussion we're having. That was the point *I* was trying to make. Shachar
Re: D web site and accessibility
On Sunday, 23 September 2018 at 22:07:36 UTC, Walter Bright wrote: I met a blind programmer at a conference back in the 80's, and had a long talk with her and how she did it. I was amazed. Ever since, I've wanted to ensure products I've worked on were accessible to the blind. It's one thing to follow guidelines, it's another to have someone who relies on a screenreader actually try it out. If anyone here uses a screenreader, or knows someone who does, please give dlang.org a try and let us know about how we can improve their experience with it. By the top of my head I can already say there are some things that don't follow accessibility standards like the use of b tags on the front page, they should be replaced by strong tags instead. Probably a few more cases too, just a real quick check.
Re: D web site and accessibility
On Monday, 24 September 2018 at 03:16:50 UTC, Bauss wrote: like the use of b tags on the front page, they should be replaced by strong tags The two usages of are part of the presentation, not content. Their use is correct.
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.
