Re: try/catch idiom in std.datetime
"Jacob Carlborg" wrote: On 2013-11-19 18:11, Jouko Koski wrote: If the "user level" validation fails, shall we throw or assert or...? Throw. Ok. What if the "user" is writing a library code which calls other system utilities? If the validation fails, is the answer now assert? I don't have a definite answer. However, I tend to follow the practice that all public API should do validation and throw on failures. I use assert for catching my own mistakes in more or less internal stuff. Usually I don't find separate validation API functions very practical. One can forget or ignore to do validation, just like one can fail to check errno after a call. Of course, validation is necessary and exceptions can assert (sic!) this. It might be more of a personal preference, but often I catch exceptions only for error reporting purposes. Exception is an indication of an unexpected condition in the program. The solution is to fix the program to be prepared for the condition, not trying to fix the condition afterwards as the exception has already fired. Not all APIs support this approach. -- Jouko
Re: try/catch idiom in std.datetime
"Jacob Carlborg" wrote: I would say that it would be quite cumbersome and verbose to for the user to constantly validate the input. If the "user level" validation fails, shall we throw or assert or...? -- Jouko --- avast! Antivirus käynnissä, joten tässä sähköpostiviestissä ei ole viruksia tai haittaohjelmia. http://www.avast.com
Re: DConf 2013 official car/room sharing thread
"Walter Bright" wrote: I nearly got run over several times just walking around London! Me too, but then I realized that they have left side traffic there. :-) -- Jouko
Re: C++ guys hate static_if?
"Nick Treleaven" wrote: On 09/03/2013 11:15, Artur Skawina wrote: > - static-if not creating scopes/is/ confusing, but what would be a > better > alternative? Isn't it only confusing to newbies? It's not hard to learn and recognize. Maybe. This is just precisely the way how it all begun in C/C++. -- Jouko
Re: C++ guys hate static_if?
"Walter Bright" wrote:
Many of the criticisms in the paper are addressed by our positive
experience with static if in D.
Sometimes I do find it confusing that { does or does not introduce a new
scope in a very similar-looking contexts.
--
Jouko
Re: Exception/Error division in D
"deadalnix" wrote: Le 31/05/2012 04:10, Walter Bright a écrit : The correct response to a server app crashing is to restart it, not attempt to keep a program in an invalid state running. Should I mention to restart it AFTER A GRACEFUL SHUTDOWN ? No. Abort with crash dump is good way to do controlled shutdown. If there is need for a cleanup, it is better to do it in the upcoming startup where the program state is valid.
Re: Line lengths discussed in eclipse forum and on reddit
"Andrei Alexandrescu" wrote: Anyhow, let's move on to date formats. I'm archiving some receipt right now, and I find the mm/dd/yy notation notation quite unpleasant... Touché! :-) -- Jouko
Re: Any D developer at GDC europe next week ?
"Peter Alexander" wrote: Almost everyone in the games industry knows that C++ is a rubbish language. When I talk about D programming language to somebody, I prefer avoiding this sort of argumentation entirely. -- Jouko
Re: Any D developer at GDC europe next week ?
"Nick Sabalausky" wrote: Any sentence involving the phrases "C++" and "it works" needs to be appended with something like "...sort of" or "...barely". When I talk about D programming language to somebody, I prefer avoiding this sort of tone entirely. -- Jouko
Re: Rename std.ctype to std.ascii?
"Jonathan M Davis" wrote: On 2011-06-14 11:53, Jouko Koski wrote: I would not consider it being good idea to include this kind of ascii-only utilities in the standard-ish library. For some classes of operations, it makes perfect sense to be checking for ASCII characters only. For others, it's just people not worrying about internationalization like they should be. For instance, format strings don't care about unicode as far as their escape sequences go. %a, %d, etc. are all pure ASCII. Do we really need a common library utility for such a bounded domain? I would vote dropping ascii-only std.ctype altogether. Those who know and ensure that they are dealing with ascii-only, ebcdic-only or whatever-only representations can easily write their own utilities to their particular domains - maybe even better optimized than std.ctype because the domain may be even more restricted. A common use ascii-only utility will be used inevitably in places where it shouldn't. std.ctype/std.ascii deals with ASCII for those situations where you really do only care about ASCII. It deals with unicode characters, but it returns false for everything with them which returns a bool, and it never tries to change their case. std.uni actually deals with unicode and worries about things like whether a unicode character is uppercase or not. That is what (or ) utilities do when the default locale setting is in effect. Some other posters seem to suggest that a more generalized library module does this, too, without losing performance. -- Jouko
Re: Rename std.ctype to std.ascii?
"Jonathan M Davis" wrote: So, yes I understood. It's just that as far as I can tell, locales don't matter if you're completely restricting yourself to ASCII like std.ctype does. I would not consider it being good idea to include this kind of ascii-only utilities in the standard-ish library. It might be best to rename the module to std.ascii_for_insular_yankees_others_keep_away so that nobody would use it by accident. This way the name would also remind us about the historical terms which were used quarter of a century ago when ascii-only utilities were first suggested to the intenational C standardization committee. -- Jouko
Re: Rename std.ctype to std.ascii?
"Jonathan M Davis" wrote: std.ctype is modeled after C's ctype.h. It has functions for operating on characters - particularly functions which indicate the type of a character (I believe that ctype stands for character type, so that makes sense). For instance, isdigit will tell you whether a particular character is a digit. It only works on ASCII characters (non-ASCII characters return false for functions like isdigit and functions like toupper do nothing to non-ASCII characters). What is your definition for ASCII character? Most of the functions (or macros) are locale dependent, see setlocale() and . And there is the , too. While the C standardized ways of doing things might not be most appropriate approach in D domain, we must not base our design decisions on deficient analysis. "I just want this text uppercase" is one of the hardest things in the _world_. The problem is not just the header or package naming. -- Jouko
Re: float equality
"Walter Bright" wrote: A reasonable way to do financial work is to use longs to represent pennies. After all, you don't have fractional cents in your accounts. I tend to favor using floating point, doing calculations in pennies, and explicitly rounding result to nearest full penny. This is almost the same as using longs except that division does not always truncate numbers. Fractional pennies are often useful in intermediate results. If there is some more appropriate type to use, I might be easily convinced otherwise. However, I don't think using some indefinite precision number type is a fits-for-all solution either, since... I.e. you have to know what you're doing :-) Touche! -- Jouko
