Re: simple (I think) eponymous template question ... what is proper idimatic way ?
On Wednesday, 18 August 2021 at 05:33:13 UTC, james.p.leblanc
wrote:
If I wanted to ensure that a function accepts only arguments of
byte, int, uint, long, etc. (i.e. integer-like types). Is the
accepted way to do this like so?:
**auto foo( T : long )(T a, T b){ ... }**
I very much prefer the ususal constraint syntax
**auto foo(T)(T a, T b) if(isIntegral!T) { ... }**
Re: (Oh My) Gentool 0.3.0 released
On Wednesday, 5 May 2021 at 11:54:51 UTC, user1234 wrote: On Wednesday, 5 May 2021 at 10:01:13 UTC, user1234 wrote: Maybe some time in future, but for now there is a lot more priority stuff to do before even attempting this. Thanks for the explanations. BTW I had the same question for LDC backend being c++, I guess the answer would be similar. Yeah, but unlike LDC, for a tool that translates C++ to D it is a goal being able to also translate itself from C++ to D. And reaching this goal would be a huge milestone!
Re: (Oh My) Gentool 0.3.0 released
On Wednesday, 5 May 2021 at 10:01:13 UTC, user1234 wrote: I have a technical question about the tool itself. It is mostly written in cpp. Oh dear! Isn't it possible to use it to translate itself into D?
Re: GC.addRange in pure function
On Tuesday, 9 February 2021 at 21:00:39 UTC, Paul Backus wrote: On Tuesday, 9 February 2021 at 19:53:27 UTC, Temtaime wrote: pure is broken. Just don't [use it] Allowing memory allocation in pure code in a language that can distinguish between pointer equality and value equality is, let's say, "unprincipled." pure in D is a very useful concept, even if it's not literally the same as pure in functional languages. Recommending not to use it is bad advice IMHO.
Re: List of exceptions?
On Saturday, 10 October 2020 at 19:51:10 UTC, DMon wrote: This is where I'm at: import std.stdio; import std.conv; // StdioException // ConvException // StringException // ErrnoException // FormatException // UnicodeException // UTFException // FileMissingException // DataCorruptionException // FE_INEXACT // FE_UNDERFLOW // FE_OVERFLOW // - You should not care about exceptions someone else defined in his library (maybe except for printing out their message in main(), for which you don't need to know the exact type). - You should not reuse exceptions defined by someone else. Define your own. - Throw exceptions only if you have a plan what to do with them if you catch them. - If you have no plan, better throw error, just to get an idea where and why the program crashed (and don't try to catch them) Therefore a list of possible exceptions doesn't make any sense.
Re: Why is BOM required to use unicode in tokens?
On Wednesday, 16 September 2020 at 07:38:26 UTC, Dominikus Dittes Scherkl wrote: We only need to define which properties a character need to be allowed in an identifier. I think the following change in the grammar would be sufficient: Identifier: IdentifierStart IdentifierStart IdentifierChars IdentifierChars: IdentifierChar IdentifierChar IdentifierChars IdentifierStart: _ Any Unicode codepoint with general category Lu, Ll, Lt, Lo, Nl or No IdentifierChar: IdentifierStart Any Unicode codepoint with general category Lm, Mn, Me, Mc or Nd
Re: Why is BOM required to use unicode in tokens?
On Wednesday, 16 September 2020 at 00:22:15 UTC, Steven Schveighoffer wrote: Someone should verify that the character you want to use for a symbol name is actually considered a letter or not. Using phobos to prove this is kind of self-defeating, as I'm pretty sure it would be in league with DMD if there is a bug. UnicodeData.txt (a data file provided by the unicode organization itself since version 1) contains exactly the necessary properties (in an easy parsable format), so we don't need to hard-code the list of allowed identifier characters, but can instead use the latest version provided by unicode (changing every year!). We only need to define which properties a character need to be allowed in an identifier.
Re: Why is BOM required to use unicode in tokens?
On Tuesday, 15 September 2020 at 06:49:08 UTC, Jon Degenhardt wrote: On Tuesday, 15 September 2020 at 02:23:31 UTC, Paul Backus wrote: Identifiers start with a letter, _, or universal alpha, and are followed by any number of letters, _, digits, or universal alphas. Universal alphas are as defined in ISO/IEC 9899:1999(E) Appendix D of the C99 Standard. I was unable to find the definition of a "universal alpha", or whether that includes non-ascii alphabetic characters. ISO/IEC 9899:1999 (E) Annex D Universal character names for identifiers - Latin: 00AA, 00BA, 00C0-00D6, 00D8-00F6, 00F8-01F5, 01FA-0217, 0250-02A8, 1E00-1E9B, 1EA0-1EF9, 207F Greek: 0386, 0388-038A, 038C, 038E-03A1, 03A3-03CE, 03D0-03D6, 03DA, 03DC, 03DE, 03E0, 03E2-03F3, 1F00-1F15, 1F18-1F1D, 1F20-1F45, 1F48-1F4D, 1F50-1F57, 1F59, 1F5B, 1F5D, 1F5F-1F7D, 1F80-1FB4, 1FB6-1FBC, 1FC2-1FC4, 1FC6-1FCC, 1FD0-1FD3, 1FD6-1FDB, 1FE0-1FEC, 1FF2-1FF4, 1FF6-1FFC Cyrillic: 0401-040C, 040E-044F, 0451-045C, 045E-0481, 0490-04C4, 04C7-04C8, 04CB-04CC, 04D0-04EB, 04EE-04F5, 04F8-04F9 Armenian: 0531-0556, 0561-0587 Hebrew: 05B0-05B9, 05BB-05BD, 05BF, 05C1-05C2, 05D0-05EA, 05F0-05F2 Arabic: 0621-063A, 0640-0652, 0670-06B7, 06BA-06BE, 06C0-06CE, 06D0-06DC, 06E5-06E8, 06EA-06ED Devanagari: 0901-0903, 0905-0939, 093E-094D, 0950-0952, 0958-0963 Bengali: 0981-0983, 0985-098C, 098F-0990, 0993-09A8, 09AA-09B0, 09B2, 09B6-09B9, 09BE-09C4, 09C7-09C8, 09CB-09CD, 09DC-09DD, 09DF-09E3, 09F0-09F1 Gurmukhi: 0A02, 0A05-0A0A, 0A0F-0A10, 0A13-0A28, 0A2A-0A30, 0A32-0A33, 0A35-0A36, 0A38-0A39, 0A3E-0A42, 0A47-0A48, 0A4B-0A4D, 0A59-0A5C, 0A5E, 0A74 Gujarati: 0A81-0A83, 0A85-0A8B, 0A8D, 0A8F-0A91, 0A93-0AA8, 0AAA-0AB0, 0AB2-0AB3, 0AB5-0AB9, 0ABD-0AC5, 0AC7-0AC9, 0ACB-0ACD, 0AD0, 0AE0 Oriya: 0B01-0B03, 0B05-0B0C, 0B0F-0B10, 0B13-0B28, 0B2A-0B30, 0B32-0B33, 0B36-0B39, 0B3E-0B43, 0B47-0B48, 0B4B-0B4D, 0B5C-0B5D, 0B5F-0B61 Tamil: 0B82-0B83, 0B85-0B8A, 0B8E-0B90, 0B92-0B95, 0B99-0B9A, 0B9C, 0B9E-0B9F, 0BA3-0BA4, 0BA8-0BAA, 0BAE-0BB5, 0BB7-0BB9, 0BBE-0BC2, 0BC6-0BC8, 0BCA-0BCD Telugu: 0C01-0C03, 0C05-0C0C, 0C0E-0C10, 0C12-0C28, 0C2A-0C33, 0C35-0C39, 0C3E-0C44, 0C46-0C48, 0C4A-0C4D, 0C60-0C61 Kannada: 0C82-0C83, 0C85-0C8C, 0C8E-0C90, 0C92-0CA8, 0CAA-0CB3, 0CB5-0CB9, 0CBE-0CC4, 0CC6-0CC8, 0CCA-0CCD, 0CDE, 0CE0-0CE1 Malayalam: 0D02-0D03, 0D05-0D0C, 0D0E-0D10, 0D12-0D28, 0D2A-0D39, 0D3E-0D43, 0D46-0D48, 0D4A-0D4D, 0D60-0D61 Thai: 0E01-0E3A, 0E40-0E5B Lao: 0E81-0E82, 0E84, 0E87-0E88, 0E8A, 0E8D, 0E94-0E97, 0E99-0E9F, 0EA1-0EA3, 0EA5, 0EA7, 0EAA-0EAB, 0EAD-0EAE, 0EB0-0EB9, 0EBB-0EBD, 0EC0-0EC4, 0EC6, 0EC8-0ECD, 0EDC-0EDD Tibetan: 0F00, 0F18-0F19, 0F35, 0F37, 0F39, 0F3E-0F47, 0F49-0F69, 0F71-0F84, 0F86-0F8B, 0F90-0F95, 0F97, 0F99-0FAD, 0FB1-0FB7, 0FB9 Georgian: 10A0-10C5, 10D0-10F6 Hiragana: 3041-3093, 309B-309C Katakana: 30A1-30F6, 30FB-30FC Bopomofo: 3105-312C CJK Unified Ideographs: 4E00-9FA5 Hangul: AC00-D7A3 Digits: 0660-0669, 06F0-06F9, 0966-096F, 09E6-09EF, 0A66-0A6F, 0AE6-0AEF, 0B66-0B6F, 0BE7-0BEF, 0C66-0C6F, 0CE6-0CEF, 0D66-0D6F, 0E50-0E59, 0ED0-0ED9, 0F20-0F33 Special characters: 00B5, 00B7, 02B0-02B8, 02BB, 02BD-02C1, 02D0-02D1, 02E0-02E4, 037A, 0559, 093D, 0B3D, 1FBE, 203F-2040, 2102, 2107, 210A-2113, 2115, 2118-211D, 2124, 2126, 2128, 212A-2131, 2133-2138, 2160-2182, 3005-3007, 3021-3029 --- This is outdated to the brim. Also it doesn't allow for letter-like symbols (which is debatable, but especially the mathematical ones like double-struck letters are intended for such use). Instead of some old C-Standard, D should better rely directly on the properties from UnicodeData.txt, which is updated with every new unicode version.
Re: Named parameters in function call
On Tuesday, 8 September 2020 at 13:28:22 UTC, Cecil Ward wrote:
int xcoord;
int ycoord;
You can define your own types, of course:
struct xcoord { int x; alias x this; }
struct ycoord { int y; alias y this; }
void myfunc(xcoord x; ycoord y, color c) {}
Re: Idiomatic D code to avoid or detect devision by zero
On Monday, 3 August 2020 at 14:50:36 UTC, Steven Schveighoffer wrote: On 8/3/20 5:53 AM, Martin Tschierschke wrote: I prefer putting additional bracket around For really long expressions you could also split it on multiple lines: c = (b_expression == 0) ? (d_longer_expression) : (a_expression/b_expression);
Re: uncovered: code coverage summary tool
On Tuesday, 21 July 2020 at 20:39:54 UTC, Mario Kröplin wrote: https://github.com/linkrope/uncovered examines coverage listing files to identify the ones with the most uncovered lines. Was this done with the new coverage check during CTFE? I would expect the numbers to be better then...
Re: how to assign to shared obj.systime?
On Tuesday, 14 July 2020 at 07:05:43 UTC, Arafel wrote: *However*, for this to work, you shouldn't use `shared` member variables unless absolutely necessary, much less whole `shared` classes/structs This is generally true. Avoid sharing many variables! Tasks should be as independent from each other as possible. Anything else is bad design doomed to run into problems sooner or later. Also there is really almost never a good reason to share whole classes or nested structures.
Re: How can I make executeShell ask for Admin Elevation?
On Monday, 13 July 2020 at 19:32:33 UTC, Marcone wrote:
alias runas = compose!(x => to!bool((cast(int) x) > 32), x =>
ShellExecute(null, "runas", "cmd", cast(wchar*) "/c \"cd /d %s
&& %s\"".format(getcwd(), x).to!wstring, null,
SW_HIDE).WaitForSingleObject(WAIT_TIMEOUT));
runas("netsh winhttp set proxy 127.0.0.1:9666")
Use backticks instead of doublequotes, than you don't have to
escape the doublequotes within the string. So:
alias runas = compose!(x => to!bool((cast(int) x) > 32), x =>
ShellExecute(null, "runas", "cmd", cast(wchar*)`/c "cd /d %s &&
%s"`.format(getcwd(), x).to!wstring, null, SW_HIDE);
Re: opBinary : Static ifs or specialization?
On Wednesday, 24 June 2020 at 09:01:28 UTC, claptrap wrote:
On Wednesday, 24 June 2020 at 00:53:58 UTC, H. S. Teoh wrote:
On Tue, Jun 23, 2020 at 11:53:36PM +, claptrap via
If your implementations are based on built-in operators, you
could use mixins to unify the implementations into one, e.g.:
Ah yeah thats useful, to expand a bit what about if the RHS is
a different type?
Point!T opBinary(string op, RHS)(RHS rhs)
{
static if (is(RHS == Point!float) || is(RHS ==
Point!double))
{
// .. etc..
}
else static if (is(RHS == float) || is(RHS == double))
{
// etc...
}
else static if (is(RHS == float[2]) || is(RHS == double[2]))
{
// .. etc...
}
assert(0); // type not supported
}
should that be split up?
I would say, depends on how you can implement what you need in
the shortest way (with lest code-duplication). If one operator
works with several types on RHS, but others don't, split the
operators. If all operators work the same for same RHS type but
different for different RHS types, split the types.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:24:39 UTC, Atila Neves wrote: memcpy isn't a good example since it's explicitly @system Yes, it's a good example. Because if you include any C function, you don't know if it uses memcpy internally - except if you have the code. And as memcpy is used heavily within C libraries, it's not unlikely that your "oh so safe" function is using it too. Very bad advice. It should be simply forbidden to slap @safe at anything with no code available, because @save should be reserved for mechanically verified parts of code. Ok, you can slap @trusted on it, and it will compile (the easy way), but anyone using it is at least warned. So it's possible to check - and if no body is availabe (e.g. an object library) I would refrain from trusting it. But I don't want the compiler to greenwash it for me, no thanks. There should be at least someone on the D side to blame, destroying his reputation by slapping @trusted at whole modules.
Re: __init unresolved external when using C library structs converted with dstep
On Friday, 17 April 2020 at 08:59:41 UTC, Robert M. Münch wrote: How would that look like? myStruct ms = void; // ??? Exactly.
Re: German D tutorial: HTML5 Anwendung mit GTK3 schreiben
On Thursday, 13 February 2020 at 22:48:32 UTC, Andre Pany wrote: Hi, Dieses Tutorial zeigt, wie GTK3 zum Erstellen von HTML5 Anwendungen verwendet werden kann. http://d-land.sepany.de/tutorials/gui/html5-anwendungen-mit-gtk3-schreiben Viele Grüße Andre Cool.
Re: @safe std.file.read
On Monday, 6 January 2020 at 10:07:37 UTC, WebFreak001 wrote: I was wondering, how are you supposed to use std.file : read in @safe code when it returns a void[] but you want to get all bytes in the file? Is void[] really the correct type it should be returning instead of ubyte[] when it just reads a (binary) file to memory? Or should void[] actually be castable to ubyte[] in @safe code? I definitely think it should return ubyte[]. void[] is a very special abstraction that shouldn't be used at all if you don't know very well what you're doing.
Re: Using map result type
On Tuesday, 10 December 2019 at 07:23:56 UTC, AA wrote: Would the second solution of declaring a template constraint like that be considering strange/out of place in D? e.g. do people normally try and declare the template constraints on a function or just rely on compile time failure from to instantiate template. No, you can do "normal" OOP as you like. But you will encounter the constraint approach often in phobos and other libraries, as is provides some advantages.
Re: Getting rid of const/immutable
On Monday, 16 September 2019 at 05:22:14 UTC, Cecil Ward wrote: I have a particular type name and that type may or may not be const and/or immutable. How do I make a new type based on this that is mutable, ie getting rid of both const and immutable, but not knowing what the original type is ? I don’t want to repeat information from the definition of the original type as this would introduce a bug if the original definition is later changed. Something like alias immutable_cash_t = immutable(float); alias mutable_cash_t = float; // better, in case the original were ever to be changed from ‘float’ to ‘real’ some day alias mutable_cash_t = GetRidOfImmutable!( GetRidOfConst!( mutable_cash_t ) ); If T is you const or immutable type, Unqual!T should be what you want (from std.traits) but this will also remove shared and I don't know what other modifiers there are.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On Monday, 4 February 2019 at 17:09:25 UTC, bitwise wrote:
I think this solves all of the above:
fun(10);
==>
(int __temp0){ (return)? fun( __temp0 ); }(10);
-The expression/statement issue is solved by the closure
-The initialization issue created by the ":=" approach is not
present here
-For this rewrite, 'T' is the type of the rvalue argument, not
the type of the function parameter. This prevents undesired
implicit conversions.
I don't understand this.
What does "(return)?" mean? Is this valid D syntax? What do I
miss?
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Cool. Keep it going!
Re: Shared - Another Thread
On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote: How can you find that such a construct carries its weight with respect to its rare-ness, when its usefulness is very limited to begin with? I suggested it only because of the resistance to the proposed implicit cast to shared. But I agree - a cast from mutable to immutable could also be implicit, and would rarely cause any problems. Still, I'm sure you would face equally strong resistance against that.
Re: Shared - Another Thread
On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson wrote: Mutable = value may change const = I will not change the value immutable = the value will not change unshared = I (well the current thread) owns the reference shared = reference not owned, no unordered access, no (unordered) writes threadsafe = ??? unshared = the current thread owns the reference threadsafe = I guarantee no race conditions or deadlocks will occur shared = every thread may have references
Re: Shared - Another Thread
On Friday, 19 October 2018 at 15:46:20 UTC, Stanislav Blinov wrote: On Friday, 19 October 2018 at 13:40:54 UTC, Dominikus Dittes Scherkl wrote: Conflating "shared" and "threadsave" in that manner was, I think, the biggest mistake of your proposal. He talked about it in a previous thread, and generally I would agree with him that such conflation is indeed beneficial provided that some concessions are made for `shared`. Moreover, yet another attribute? Please no... Hmm. mutable, immutable and const form a triple, the second is a declaration attribute, the last an parameter attribute, indicating that you don't want to modify the parameter, may it be because you can't (as it is immutable) or you only don't need to despite it would be possible (if it was mutable). The later is your responsibility to guarantee (with the help from the compiler). Therefore it is possible to implicitly cast from mutable or immutable to const but not in any other direction. I think for unshared, shared and threadsave it should be the same: The second is a declaration attribute, the third a parameter attribute. The first two can implicitly be cast to threadsave, may be because it is thread-local and therefore no race condition is possible, or may be because you take special care in your type to guarantee the thread safety by using atomic operations or locking or whatever. That make it possible, that the implicit cast from shared to unshared can be avoided while still providing functions that can take both kinds of arguments. Yes, that would add a little to the attribute bloat (new keyword) but not to the number of attributes per type or parameter.
Re: Shared - Another Thread
On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote: On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via Digitalmars-d wrote: On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: > [...] What issues am I failing to address? [...] Another point is the part of "how can the compiler support the expert in writing threadsave methods" - which you answered with "not a little bit at the moment, but we may improve this in the future" - and that is not at all satisfying. I think you've misunderstood. My proposal is @safe... if you stay @safe, you will receive guarantee that your code is threadsafe. On user side, yes. If you want to implement a low-level device, you must implement a @trusted function, and I don't know what the compiler can do to help you. Yes, but that's seldom. More often the "expert" will write new shared types using the low level trusted functions like anybody else. But that still requires special care - he has to consider tread-safety in every method of a new type, even the non-shared ones. And he has to fill any possible gap like construction and assignment so that the end-user is really sure to not accidentally misusing the type! And I think a serious proposal need to address this - I think the compiler could really help here (e.g. prescribe what operators need to be overloaded and check that all methods use the proper mechanisms to lock the shared members before operating on them etc.) So saying that my response that "there is @trusted code at the bottom of the stack" is not satisfying is really just a comment on your opinion about @trusted code in general. That just comes on top of it. My proposal is designed to be useful and @safe for *users* as primary goal. I agree with you, but others seem not so convinced (yet?). [...] The user has manually cast to unshared inside their unsafe/(@trusted?) function, what more signal do they need that they've engaged in an unsafe operation? Some hints what to do to be able to trust them? You asked what issues you were failing to address. That was just some ideas of mine what you may address in addition.
Re: Shared - Another Thread
On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote: What cracks me up with Manu's proposal is that it is its simplicity and lack of ambition that is criticized the most. shared is a clusterfuck, according to what I gathered from the forum, I never had yet to use it in my code. Manu's idea makes it a little less of a clusterfuck, and people attack the idea because it doesn't solve all and everything that's wrong with shared. Funny. Elaborate on this... It's clearly over-ambitious if anything. What issues am I failing to address? First of all, you called it "shared", but what your concept describes is "theadsave". If you had called it the later, it would have been clear to everybody that thread local data is indeed automatically threadsave, because only one thread has access to it (that "implicit conversion"). But if something is "shared" (in the common-world sense), it is of course no more "threadsave" - you have to implement special methods to treat it. Conflating "shared" and "threadsave" in that manner was, I think, the biggest mistake of your proposal. Another point is the part of "how can the compiler support the expert in writing threadsave methods" - which you answered with "not a little bit at the moment, but we may improve this in the future" - and that is not at all satisfying. Are there really no ideas? No check that the proper atomic funtions are used or the cast to "unshared" is ok at where it is used? Even the expert needs a little help to find the upcomming and well hidden bugs in their oh so threadsave API...
Re: shared - i need it to be useful
On Friday, 19 October 2018 at 06:25:00 UTC, rikki cattermole wrote: On 19/10/2018 7:09 PM, Norm wrote: [0] https://github.com/rikkimax/DIPs/blob/shared/DIPs/DIP1xxx-RC2.md This document provide no reasoning about what usecases it supports: Is it possible to create objects that are shared just for short periods during their livetime and guarantee that they can be used threadsave like Manu want it to be? Does it prohibit misuse any better than Manus proposal (that requires the "Expert" to implement all theadsave API)? Is the "normal" User still enforced to do some unsave casts? Has the normal User to have high knownledge of how a threadsave API is to be used or can the compiler provide any guarantees that using them can only fail if the implementation behind the API has bugs (e.g. provide some encapsulation)? Or any other usecases why and how this design is better than what we have now? And also some ideas how to implement some useacases (examples) are completely missing.
Re: shared - i need it to be useful
On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote: On 15.10.2018 20:46, Manu wrote: Assuming the rules above: "can't read or write to members", and the understanding that `shared` methods are expected to have threadsafe implementations (because that's the whole point), what are the risks from allowing T* -> shared(T)* conversion? Unshared becomes useless, and in turn, shared becomes useless. why is unshared useless? Unshared means you can read an write to it. If you give it to a function that expect something shared, the function you had given it to can't read or write it, so it can't do any harm. Of course it can handle it threadsave, but as it is local, that is only overhead - reading or changing the value can't do any harm either. I like the idea. But useless, because there is no way to ensure thread safety of reads and writes if only one party to the shared state knows about the sharing. Of course there is. Giving an unshared value to a function that even can handle shared values may create some overhead, but is indeed threadsave.
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature
wrote:
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes
Scherkl wrote:
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) : from!"std.format".FormatException?
That should work, but it's kind of a big step. In any case,
I'll never get a weird hacky template like that through code
review :)
That "weird" template is about to be added to phobos.
Since its invention one and a half year ago I use it pretty much
everywhere in my code for parameters that otherwise would require
a global import. I just wasn't sure if it would work in this
place too (that usecase never arose to me).
I don't understand, why a standard template wouldn't pass a
review.
Re: Warn on unused imports?
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature
wrote:
I'm playing with a branch of DMD that would warn on unused
imports:
https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports
Two problems have arisen.
First:
import std.stdio;
void foo(T)() { writeln("Hello World"); }
foo.d: Warning: unused import
To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.
The real problem is this:
import std.format;
class TestException(T) : FormatException { }
Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the
template scope *per se*.
I could require the class to be written as
template TestException(T) {
import std.format;
class TestException : FormatException { }
}
but that's kind of terrible.
I've been working around this for now, with import std.format :
FormatException, but I'm not really happy with it.
Any ideas?
Doesn't the "from" idiom work?
I'm not sure if it is allowed at the template declaration
template from(string moduleName)
{
mixin("import from = " ~ moduleName ~ ";");
}
class TestException(T) from!"std.format".FormatException
: FormatException
{
}
Re: code.dlang.org package list
On Monday, 10 September 2018 at 00:56:37 UTC, void wrote: On Sunday, 9 September 2018 at 06:32:39 UTC, Jonathan M Davis wrote: I downloaded 100 packages from code.dlang.org and search for "*doc*" and "*example*" Script updated now searches for the string "unittest" on package directory (*.d files only). Result: 48 packages with "unittest" Ok, this is really a scary result. Is really more than half the packages around not using unittests?!? I can't believe it...
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 22:16:25 UTC, Jonathan M Davis wrote: On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: > I think that you're crazy. No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening). - Jonathan M Davis You're underestimating the benefits. It's not just to be eventually slightly faster. It makes @safe versions possible, this in turn avoids a lot of @trusted calls, so reduces review effort. It allows also to develop own kernels (for maybe new hardware) without needing a c-toolchain an it makes D more self contained. There are certainly more advantages. And if you don't like it, the c stuff remains there for you to use.
Re: Embrace the from template?
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote: On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ I'm fine with it, public domain is great! Although I would greatly prefer object.d since I don't use dub myself. FYI Andrei has an open pull request: https://github.com/dlang/druntime/pull/1756 But it's stalled due to a bug: https://issues.dlang.org/show_bug.cgi?id=17181 Me too. I've found from meanwhile defined in so many different places, we really need it to be part of standard D. I don't get it why it can't be merged just because of a bug that affects also other local imports. Ok, with the bug it can't be used everywhere in phobos, but it remains useful in so many other places.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 04:16:45 UTC, Uknown wrote: I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like `@noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change. [0]: eel.is/c++draft/DCL.attral.noreturn The DIP mentions that, (e.g. I also don't like the syntax "@noreturn int fun()"), but I don't understand what "other uses" of a type tBottom there are, which the DIP states are not possible in C++. Especially I want a section that explains how tBottom is different from void in such situations. For functions that don't return it's clear, but else?
Re: Looking for the article comparing D to Ada and others
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote: Somebody had posted an article here on how well different languages matched certain requirements of a certain coding safety standards. I remember D was doing pretty well and I think Ada (or SPARK?) was included as well. What article? Where? But you didn't meant https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ This is about Pascal, Ada and D, but was heavily criticised because other languages were not considered after very early stage.
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1016, "ref T accepts r-values": https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md +1 The DIP reduces bloat, doesn't brake existing code, and I can't see downsides.
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 17:49:19 UTC, H. S. Teoh wrote: On Wed, Jul 18, 2018 at 11:30:21AM -0600, Jonathan M Davis via On the other hand, if opCmp is allowed to return a user-defined type, it would solve the problem in a neat way: just define a quaternary type that encapsulates the values -1, 0, 1, NaN, and have opCmp return the equivalent of NaN for non-comparable arguments. Then we could support partial orders correctly. But I have a hard time seeing this actually work in practice, because a user-defined return type for opCmp leads to recursion: It already works with float, no recursion. A lot of the types I use depend on this. But having a language supported quarterny type would be good for its improved speed.
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 17:30:21 UTC, Jonathan M Davis wrote: On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote: Just do what std.typecons.Proxy does and return float.nan for the incomparable case. Since when is that legal? I thought that it was required for opCmp to return int. Certainly, the spec implies that it has to be int. The fact that the compiler allows it seems like a bug, though if Phobos is doing it, it wouldn't surprise me if Walter would choose to update the spec rather than fixing the compiler. It always worked with float as returntype (at least since I'm using D - about 2.40 or so?), and it was necessary for the (unfortunately deprecated) special operators <>, !<>, <>=, !<>=, ... would really pissing me off if someone deemed this excellent feature beeing a bug and removed it. The OP already found out that some valuable mathematical concepts doesn't work with only 3 values for opCmp. The 4th value is essencial.
Re: opCmp / opEquals do not actually support partial orders
On Wednesday, 18 July 2018 at 13:12:05 UTC, Ivan Kazmenko wrote:
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote:
Just do what std.typecons.Proxy does and return float.nan for
the incomparable case.
Isn't it slow though on current processors? I just threw
together a test program.
Leaving x uninitialized, or using floats, work about the same.
No, floats are a whole lot less slow.
But I agree, I would still prefer to have a signed bool which
uses only 1 byte
and provide _much_ faster comparison to NaN. And I have created
one,
but as it is not supported by the language natively, it
internally has to use
float, so is not faster (or even slower):
/// signed boolean type (2bit), has the values neg (0b11), zero
(0b00), pos (0b01) and nan (0b10)
/// this is an extended boolean that split "true" into
positive/negative and "false" into zero/NaN
struct sbool
{
pure:
@safe:
@nogc:
nothrow:
enum { neg = 0b11, zero = 0b00, pos = 0b01, nan = 0b10 };
this(T)(const(T) x) if(isNumeric!T)
{
static if(is(Unqual!T == sbool))
val = x.val; /// pos -> 1, neg -> 3, zero -> 0, nan -> 2
else static if(is(Unqual!T == bool))
val = x ? pos : zero;
else static if(isUnsigned!T)
val = x.isInvalid ? nan : (x>0) ? pos : zero;
else // signed or safe signed
val = x.isInvalid ? nan : (x<0) ? neg : (x>0) ? pos :
zero;
}
T opCast(T)() const if(isNumeric!T)
{
static if(is(Unqual!T == sbool))
return this;
else static if(is(Unqual!T == bool))
return val&1; // pos and neg are mapped to true, zero
and NaN are mapped to false
else static if(isFloatingPoint!T)
return tsgn[val];
else
return val == nan ? invalid!T : cast(T)tsgn[val];
}
sbool opAssign(T)(const(T) x) if(isNumeric!T)
{
return this(x);
}
sbool opOpAssign(string op)(const sbool x) if(op == "+" || op
== "-" || op == "*" || op == "/" || op == "%")
{
static if(op == "+") // attention! pos+neg = neg+pos = nan
!!
val = tadd[val];
else static if(op == "-") // attention! pos-pos = neg-neg =
nan !!
val = tsub[val];
else static if(op == "*")
val = tmul[val];
else static if(op == "/")
val = tdiv[val];
else static if(op == "%")
val = trem[val];
val >>= x.val<<1;
val &= 3;
return this;
}
sbool opUnary(string op)() if(op == "++" || op == "--")
{
mixin(op~"val");
val &= 3;
return this;
}
sbool opUnary(string op)() const if(op == "+" || op == "-" ||
op == "~")
{
static if(op == "+") return this;
sbool r = this;
mixin("r.val = "~op~"r.val");
r.val &= 3;
return r;
}
sbool opBinary(string op)(const(sbool) x) const if(op == "+"
|| op == "-" || op == "*" || op == "/" || op == "%")
{
sbool r = this;
return mixin("r "~op~"= x");
}
Signed!T opBinary(string op, T)(const(T) x) const
if(isNumeric!T && op == "*")
{
static if(isUnsigned!T)
{
alias R = Signed!T;
if(val == nan || x.isInvalid) return invalid!R;
if(val == zero) return 0;
if(x > R.max) return invalid!R;
return (val == pos) ? R(x) : -R(x);
}
else // signed or float: return type is same as T
{
if(x.isInvalid) return x;
final switch(val)
{
case pos: return x;
case neg: return -x;
case zero: return 0;
case nan: return invalid!T;
}
}
}
Signed!T opBinaryRight(string op, T)(const(T) x) const
if(isNumeric!T && op == "*")
{
return opBinary!"*"(x);
}
private:
ubyte val = nan;
static immutable float[4] tsgn = [ 0.0f, 1.0f, float.init,
-1.0f ];
// composition tables 0: -1 N 1 0 1: -1 N 1
0 N: -1 N 1 0 -1: -1 N 1 0
static immutable ubyte[4] tadd = [ 0b_11_10_01_00,
0b_10_10_01_01, 0b_10_10_10_10, 0b_11_10_10_11 ];
static immutable ubyte[4] tsub = [ 0b_01_10_11_00,
0b_01_10_10_01, 0b_10_10_10_10, 0b_10_10_11_11 ];
static immutable ubyte[4] tmul = [ 0b_00_10_00_00,
0b_11_10_01_00, 0b_10_10_10_10, 0b_01_10_11_00 ];
static immutable ubyte[4] tdiv = [ 0b_00_10_00_10,
0b_11_10_01_10, 0b_10_10_10_10, 0b_01_10_11_10 ];
static immutable ubyte[4] trem = [ 0b_00_10_00_10,
0b_01_10_01_10, 0b_10_10_10_10, 0b_11_10_11_10 ];
// remainder table is designed so, that if you define
// quot = (abs(a)/abs(b)) * (sbool(a)/sbool(b));
// rem = (abs(a)%abs(b)) * (sbool(a)%sbool(b));
// then assert(a == quot*b + rem) holds for all (a,b) with
b != 0
}
unittest
{
byte quot, rem;
for(byte a = 127; a >= -127; --a)
{
for(byte b = 127; b >= -127; --b)
{
quot = cast(byte)( (abs(a)/abs(b)) * (sbool(a)/sbool(b))
);
rem = cast(byte)( (abs(a)%abs(b)) * (sbool(a)%sbool(b))
);
assert((b == 0 && isInvalid(quot) &&
Re: opCmp / opEquals do not actually support partial orders
On Tuesday, 17 July 2018 at 21:18:12 UTC, John Colvin wrote: On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote: But opCmp turns out to be a tarpit. Here's why: According to the original claim, it should also return 0, for "incomparable". However, this leads to problems: Indeed. And it doesn't make sense at all. Just do what std.typecons.Proxy does and return float.nan for the incomparable case. Yes, that's the only way. Having this 4th value of opCmp is necessary for may types. In fact opCmp() it practically the only place where I ever use the type "float", just to have the NaN. If I really need floatingpoint arithmetic, I always use real (or at least double). I would like to have a "signed boolean" type (with the values -1, 0, 1 and NaN) simply for all kind of sign operations. But ok, float is 32bit, and IEEE suggests a "half" type (16bit). As a "signed boolean" would need a byte anyway there is no too much to gain.
Re: Feature to get or add value to an associative array.
On Thursday, 19 April 2018 at 08:20:02 UTC, Giles Bathgate wrote: On Wednesday, 18 April 2018 at 21:04:53 UTC, Jordan Wilson wrote: Thinking seems sound, although having a name starting with "get" does have the advantage of being more related to the existing get. Ah yes, good point. I think now we've had the discussion about other use cases though that ultimately there might need to be an "atomic" AddOrUpdate style function too, which I was thinking could just be called 'update'. The necessity to keep them all starting with get seemed less important. How about something like "forceGet" to make clear you will get it, even if it wasn't there before.
Re: Can't add ubytes together to make a ubyte... bug or feature?
On Saturday, 17 March 2018 at 18:36:35 UTC, Jonathan wrote: On Tuesday, 19 January 2016 at 23:36:14 UTC, Adam D. Ruppe wrote: On Tuesday, 19 January 2016 at 22:12:06 UTC, Soviet Friend wrote: I don't care if my computer needs to do math on a 4 byte basis, I'm not writing assembly. x86 actually doesn't need to do math that way, if you were writing assembly, it would just work. This is just an annoying rule brought over by C. Can I prevent the initial implicit casts? Nope, though you can help tell the compiler that you want it to fit there by doing stuff like ubyte a = 200; ubyte b = 100; ubyte c = (a+b)&0xff; or something like that, so the expression is specifically proven to fit in the byte with compile time facts. `(a+b)&0xff` What is this syntax?! Could you give a link to this in the D documentation? I am not even sure how to look it up... & is the normal binary and operation, same in C, C++, Java, ... 0xFF is a hexadecimal constant (255), which the compiler knows fit in an ubyte So what do you not understand about this syntax?
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Friday, 9 February 2018 at 11:16:01 UTC, Nick Sabalausky (Abscissa) wrote: /** Be sure to check the various files at extras/foo*/package.d and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html */ Unlike the "disabling code that contains the end-of-disabled-code token" stuff, THIS example isn't quite so trivial to deal with in a way that's reasonably readable from both the generated docs and from within the code itself. How about // Be sure to check the various files at extras/foo*/package.d // and also: https://gcc.gnu.org/onlinedocs/libstdc++/faq.html The good part of having multiple comment starters is that you can pick the one that works best with a specific text you would like to add as a comment. // goes to the end of the line, so the text can be pretty much anything (except for EOL of course), so is a good fallback.
Re: Run-time initialised static variables
On Wednesday, 7 February 2018 at 12:10:38 UTC, dekevin wrote:
struct ℚ{
ℤ num, den; //cannot call constructors on these, since
they require gmp_init, which requires runtime code
//Default initialiser disabled, since else num=0,den=0
You can use a different default initializer:
ℤ num = 0, den = 1;
Thus avoiding the bad denominator.
Re: Annoyance with new integer promotion deprecations
On Wednesday, 7 February 2018 at 01:06:42 UTC, Luís Marques wrote:
On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote:
I really like your .nx idea! It neatly sidesteps the
nonsensical mandatory casts and on top of that documents
intent (the .nx being a telltale sign of truncation -- much
better than arbitrary implicit rules).
[...]
Yeah, it's just a thin wrapper. I implemented just enough to
cover my use cases but just in case it's useful to you or
someone else, here goes my implementation...
Very cool! Much better than implementing new types.
Just
auto opBinary(string op, U)(NX!U rhs)
{
static if(rhs.value.sizeof > value.sizeof)
return mixin("rhs " ~ op ~ " value");
That won't do anything good for operators that are NOT commutative
(like -, ^^, <<, >>, %, /, ...)
Seems you don't use other things than +, *, &, | and ^, do you?
Re: Annoyance with new integer promotion deprecations
On Tuesday, 6 February 2018 at 07:15:33 UTC, Walter Bright wrote: The thing is, when there are mixed integer sizes and signedness, there is no intuitive and correct solution. Each set of rules comes with its own set of cases where there are unintuitive behaviors. So, why doing any promotion at all? If two different types are used in an arithmetic operation, the larger of those two types should be the result type. And if the result would be truncated in some way, return NAN. Every type should have a NAN value. For the signed types the extra useless .min is a perfect candidate for a NAN. That allows -x to always be of the same type as x, which I think is a good thing(tm). Fortunately, in D is't absolutely easy to define just that kind of types that fullfill all these requirements. Its about 100 LOC. I call them sbyte, sword, sint and slong which are even better names than the original ones (because they directly indicate that they are signed and match the unsigned ones). So I never again bother with the completely nuts builtin signed types.
Re: LDC 1.7.0
On Tuesday, 30 January 2018 at 11:44:11 UTC, Dominikus Dittes Scherkl wrote: I think they update only stuff for which security problems were fixed and everything that depends on those, and that's it. And by the way, for some people that is the reason to install such a kind of distro: to not be suprised by any updates that destroy your dependencies or change the behavior in any unexpected way. If you like, you can update a package any time by yourself, if that is necessary. To be always up to date I would recommend a different kind of distro.
Re: LDC 1.7.0
On Tuesday, 30 January 2018 at 09:38:26 UTC, aberba wrote: On Monday, 29 January 2018 at 07:40:10 UTC, Dominikus Dittes Scherkl wrote: On Saturday, 27 January 2018 at 21:42:49 UTC, aberba wrote: [...] Ubuntu 16.04 This is a long-term support distribution. Don't expect those to have actual tip versions of any SW package! They rely on stabe versions that don't have the latest features but only those very well tested. The semver 1.7 is not an unstable package. Its that their reason for no updates? I don't know their exact update policy, but generally the Long-Term support distros tend to have rather old packages for a lot of sw. I think they update only stuff for which security problems were fixed and everything that depends on those, and that's it.
Re: LDC 1.7.0
On Saturday, 27 January 2018 at 21:42:49 UTC, aberba wrote: [...] Ubuntu 16.04 This is a long-term support distribution. Don't expect those to have actual tip versions of any SW package! They rely on stabe versions that don't have the latest features but only those very well tested.
Re: New integer promotion rules
On Thursday, 18 January 2018 at 06:05:08 UTC, rumbu wrote: On Thursday, 18 January 2018 at 02:30:17 UTC, Rubn wrote: On Wednesday, 17 January 2018 at 22:30:11 UTC, rumbu wrote: code like "m = n < 0 ? -n : n" doesn't worth a wrapper That code is worth a wrapper, it's called "abs"... m = abs(n); Well, since I'm in the learn forum and you seem to have a response to anything, can you help me translate this line under the new integer promotion rules? https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L7804 Thanks. target = isNegative ? cast(Unsigned!T)(-c) : cast(Unsigned!T)c; That would have been better even before the change, because the operator '-' used on unsigned types is likely to produce unexpected results, if the behaviour is defined at all.
Re: Proposed Phobos equivalent of wcswidth()
On Monday, 15 January 2018 at 15:08:24 UTC, Kagamin wrote: columnWidth as it only makes sense for column-oriented text display. I think displayWidth is better, because "width" is directly linked to hozizontal direction (else it would be called hight), and setting text in colums would still take additional steps to be set correct. Also "display" indicates that it has nothing to do with the string length, which is good to avoid confusion.
Re: static array with inferred size
On Thursday, 21 September 2017 at 13:58:14 UTC, Timon Gehr wrote: On 21.09.2017 12:33, Per Nordlöw wrote: On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote: Can that be done without breakages? -- Andrei No. Are thinking about typeof([1,2]) changing from int[] to int[2] ? Yes, and everything that entails, for example: auto x = [1,2]; x ~= 3; // goes from ok to `error: cannot append int to int[2]`. Ok, breaks code, but I like it. Much better than the current behaviour.
Re: How to specify a template that uses unqualified type, like any normal function
On Tuesday, 15 August 2017 at 14:24:57 UTC, Steven Schveighoffer
wrote:
What IFTI would need is a mechanism to change the parameter
types to mutable similar to how you can do this:
foo(T)(const(T) t);
This now generates one function for int, const(int),
immutable(int), and t is const within the function.
What we need is something like:
foo(T)(mutable(T) t) // fictitious type constructor, doesn't
work.
In fact, that was the first thing I tried, but it doesn't exist.
Would be a pretty useful addition anyway, because it would allow
(some time in the far future) to move from mutable by default to
immutable by default.
Or a more general mechanism to modify IFTI when it is deciding
the parameters to use based on the call.
In my case, I've run into this when I'm trying to use short or
ubyte, and someone uses literals:
void foo(short s) { ...}
void fooT(T)(T t) { foo(s); }
foo(1); // ok
fooT(1); // error.
It would be nice if there was some way to tell IFTI to infer T
as short in this case.
Yes, that would also be very nice. And would be easy to solve:
A literal should always be assumed to be the smallest type that
can represent it, not int. May be, if compatibilitpy to old bad C
is really still so important, integer propagation can be done
later on if neccessary, but don't start out with int. That's just
so oldschool and most of the time just annoying and there's no
technical reason to do so.
Re: How to specify a template that uses unqualified type, like any normal function
On Monday, 14 August 2017 at 17:43:44 UTC, Dominikus Dittes
Scherkl wrote:
On Monday, 14 August 2017 at 15:20:28 UTC, Steven Schveighoffer
wrote:
What you can do, is:
auto foo(T)(T n) if (is(T == Unqual!T))
{
// normal implementation
}
auto foo(T)(T n) if (!is(T == Unqual!T) &&
isImplicitlyConvertible!(T, Unqual!T))
{
return foo!(Unqual!T)(n);
}
Ok, I'll try that out.
Yeah, works fine. I've improved this to
T foo(T)(T n)
{
static if(!is(Unqual!T == T)) return foo!(Unqual!T)(n);
else
{
// normal implementation
}
}
So it's basically 2 lines of overhead. That's acceptable. The
check for isImplicitlyConvertible is not necessary, because if
it's not it will error out anyway.
As this in fact leads to some decrease in code size (as the
instances for const or shared parameters are now much smaller or
in fact completely removed by the inliner, much less template
code duplication happens), I will add this to a lot of templates
- seems this will become some sort of standard D boilerplate code.
Thanks for the help!
Re: How to specify a template that uses unqualified type, like any normal function
On Monday, 14 August 2017 at 15:20:28 UTC, Steven Schveighoffer
wrote:
On 8/14/17 9:48 AM, Dominikus Dittes Scherkl wrote:
> uint foo(T)(Unqual!T n) // first try
> {
> ++n; // modify should be possible
> return 42;
> }
> Any ideas what I need to do to make this work?
This isn't exactly supported. Implicit Function Template
Instantiation (IFTI) will deduce the parameters to be the types
that you pass in. You can't deduce them and then change the
parameter types. This is a limitation of IFTI that I have
struggled with in the past.
A little unfortunate, because I would consider this the standard
usecase.
You only overload functions if they do something special with
const or shared or immutable parameters, but for templates you
get a different implementation for these all the time, and you
didn't even have a chance to avoid that useless code-bloat? What
a pitty.
What you can do, is:
auto foo(T)(T n) if (is(T == Unqual!T))
{
// normal implementation
}
auto foo(T)(T n) if (!is(T == Unqual!T) &&
isImplicitlyConvertible!(T, Unqual!T))
{
return foo!(Unqual!T)(n);
}
Ok, I'll try that out.
How to specify a template that uses unqualified type, like any normal function
if I use fixed-type functions, I can do the following:
uint foo(uint n)
{
++n; // modify n - as this function has received a copy of n,
this is always possible
return 42;
}
uint bar(const uint n)
{
assert(foo(n)==42);
return 17;
}
void main()
{
bar(3);
}
But if I try the same with a template parameter, it doesn't work:
import std.traits; // Unqual
uint foo(T)(Unqual!T n) // first try
{
++n; // modify should be possible
return 42;
}
uint foo2(T)(T n) // second try
{
++n; // modify fails, as T is const
return 42;
}
uint bar(T)(const T n)
{
assert(foo(n)==42u); // cannot deduce arguments - why?!?
assert(foo2(n)==42u); // here it can deduce the arguments, but
the function cannot modify n
return 17;
}
void main()
{
bar(3);
}
Any ideas what I need to do to make this work?
Re: newCTFE Status August 2017
On Friday, 11 August 2017 at 09:27:47 UTC, Stefan Koch wrote: On Tuesday, 1 August 2017 at 21:27:32 UTC, Stefan Koch wrote: [ ... ] Hey guys, I just finished &&. Hooray! So what's still missing? Or is this now complete enough to release?
Re: DIP 1011-extern(delegate)--Formal Review
On Friday, 11 August 2017 at 10:45:03 UTC, Mike Parker wrote: The first stage of the formal review for DIP 1011 [1], "extern(delegate)", is now underway. I see no problem with this DIP. And even if the usecase is rare, I think it is worth the new syntax (and thereby increased complexity of the language) to be able to do this in a type-safe way. So: +1
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On Friday, 21 July 2017 at 13:51:05 UTC, Mike Parker wrote: DIP 1009 is titled "Improve Contract Usability". I like it. I would prefer the out with two sets of parantheses.
Re: An Issue I Wish To Raise Awareness On
On Wednesday, 19 July 2017 at 22:35:43 UTC, Jonathan M Davis wrote: The issue isn't the object being destroyed. It's what it refers to via its member variables. For instance, what if an object were to remove itself from a shared list when it's destroyed (e.g. because it's an observer in the observer pattern). The object has a reference to the list, but it doesn't own it. So, even a thread-local object that has references to a shared list has to handle those as shared, even in its non-shared destructor. I can't follow your argument.
Re: If Statement with Declaration
On Wednesday, 19 July 2017 at 16:49:38 UTC, Jonathan Marler wrote:
This would automatically make it work with any statement:
with(auto x = 0) if(x)
{
doSomething
}
with(auto x = 0) while(x)
{
doSomething
}
Could also do multiple with statements
with(auto x = 0)
with(auto y = 0)
if(check(x, y))
{
doSomething
}
Yes. That's exactly the idea. Only with this synax it's worth it.
Re: If Statement with Declaration
On Wednesday, 19 July 2017 at 16:13:28 UTC, Swoorup Joshi wrote:
On Wednesday, 19 July 2017 at 15:31:08 UTC, ag0aep6g wrote:
On 07/19/2017 03:30 PM, sontung wrote:
So I was thinking of some sort of syntax like this:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?
I'd prefer a new variant of `with`:
with (int i = someFunc()) if (i >= 0)
{
// use i
}
It's slightly more verbose, but the meaning is clearer
(arguable). It extends automatically to other control
structures like `switch`.
I wouldn't have this new `with (declaration)` have the magic
lookup rules of the existing `with (expression)`. It would be
a simpler tool that I'd probably use more than the existing
`with`.
I really prefer this over if. This just made sense, just at a
glance
Me too.
Would also allow
with(char c = foo()) switch(x)
{
// use c
}
so no need to switch over the new declared variable, but still
beeing able to use it there
Re: DIP 1011--extern(delegate)--Preliminary Review Round 1
On Friday, 14 July 2017 at 10:43:05 UTC, Mike Parker wrote: DIP 1011 is titled "extern(delegate)". Looks good to me, useful, doesn't brake code, DIP seems correct.
Re: version=D_16
On Wednesday, 12 July 2017 at 09:38:13 UTC, Martin Tschierschke wrote: On Monday, 10 July 2017 at 23:01:50 UTC, Luís Marques wrote: On Monday, 10 July 2017 at 22:39:22 UTC, Petar Kirov [ZombineDev] wrote: The problem Walter pointed to is that due to integer Ah, that makes sense. Thanks for clarifying. For me it hasn't proved a problem, but I could see it being if you do a lot of arithmetic with 16-bit integers. I just want to point out, that my impression is that the maker scene using all this 16 bit Arm Arduino and what ever micro controllers, would be happy to have D as an alternative for coding in C. So BetterC and D_16 might attract a way bigger community than many other might think. Even if this reduced language might need to be named D-- :-). I would like to have a D that throw away all that integer promotion garbage anyway. We have CommonType!(), which is all we need and any promotion to a larger type than the common type of two operands does us no good in any place I can think of.
Re: vibe.d on Web Framework Benchmarks
On Wednesday, 7 June 2017 at 21:18:21 UTC, ketmar wrote: Ozan wrote: On Wednesday, 7 June 2017 at 09:44:55 UTC, Ali Çehreli wrote: Is there an issue with the tests? Surprised that vibe.d is not higher in the rating... https://www.techempower.com/benchmarks/#section=data-r14=ph=fortune Same for me. I used a lot of Java (Jetty, Tomcat) and Groovy (Grails) stuff before using D (vibe.d). On my machine I got a factor of 10-50 in difference. Vibe.d was always much faster. So where are the results coming from? most of it came from microbenchmarking. "how fast can we parse json and query db?" wow, what a great benchmark! surely, we don't need to do any data processing, let's measure raw speed of parsing data, and then throwing it away! Wow. Answer was actually visible before the OP. THAT is what I would call fast. Did you use vibe.d?
Re: [Semi-OT] to!string(enumType)
On Friday, 19 May 2017 at 21:25:22 UTC, Stefan Koch wrote:
On Friday, 19 May 2017 at 21:23:11 UTC, Dominikus Dittes
Scherkl wrote:
And it's not visible from the API or documentation - you need
to look into the source to disambiguate - I'm not convinced
and still consider this bad style.
If they take exactly the same parameters the compiler will flag
an error.
But if the parameters are merely compatible you can use static
assert, to shoot things out of the overload set.
Hm. To keep with your example:
string enumToString(E)(E v)
{
static assert(is(E == enum), ... );
}
if I want to overload it with, lets say
string enumToString(T)(T n) if(isNumeric!T)
{
}
that looks very much like "exactly the same parameters", yes?
SO it won't compile - you have stolen the overload possibility.
What kind of "merely compatible" parameters do you have in mind,
that would make your static assert pattern useful?
Re: Fantastic exchange from DConf
On Friday, 19 May 2017 at 22:06:59 UTC, Moritz Maxeiner wrote: On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes Scherkl wrote: I take this to mean the programmer who wrote the library, not every user of the library. I take this to mean any programmer that ends up compiling it (if you use a precompiled version that you only link against that would be different). Why? Because you don't have the source? Go, get the source - at least for open source projects this should be possible. I can's see the difference. Hm - we should have some mechanism to add to some list of people who already trust the code because they checked it. Are you talking about inside the code itself? If so, I imagine digitally signing the functions source code (ignoring whitespace) and adding the signature to the docstring would do it. Yeah. But I mean: we need such a mechanism in the D review process. It would be nice to have something standardized so that if I checked something to be really trustworthy, I want to make it public, so that everybody can see who already checked the code - and maybe concentrate on reviewing something that was yet not reviewed by many people or not by anybody they trust most. This is not my point of view. Especially if I had payed for some library, even legally it's not my fault if it fails. It is mine, because even if you payed for the library, when you compile it, the compiler cannot know where the library came from. Yeah, but you (should) do. For me it doesn't matter who actually compiled the code - if anything my trust would be higher if I compiled it myself, because I don't know what compiler or what settings has been used for a pre-compiled library. [the compiler] only knows you (the programmer who invoked it), as the one it extends trust to. The compiler "trusts" anybody using it. This is of no value. The important thing is who YOU trust. Or who you want the user of your program to trust. Oftentimes it may be more convincing to the user of your program if you want them to trust company X where you bought some library from than trusting in your own ability to prove the memory safety of the code build upon this - no matter if you compiled the library yourself or have it be done by company X. I am specifically not talking about what is legally your fault or not, because I consider that an entirely different matter. Different matter, but same chain of trust. nobody can check everything or even a relevant portion of it. That entirely depends on how much @trusted code you have. Of course. But no matter how glad I would be to be able to check e.g. my operating system for memory safety, and even if it would be only 1% of its code that is merely @trusted instead of @safe, it would still be too much for me. This is only feasible if you shrink you view far enough. And reverse: the more code is @safe the further I can expand my checking activities - but I still don't believe to ever being able to check everything. I specifically stated reviewing any @trusted code, not all code. Yes. Still too much, I think. I agree in principal, but the statement I responded to was "D is memory safe", which either does or does not hold. And I say: No, D is not memory safe. In practice. Good, but no 100%. I also believe that considering the statement's truthfulness only makes sense under the assumption that nothing *below* it violates that, since the statement is about language theory. Ok, this is what I mean by "shrinking your view until it's possible to check everything" - or being able to prove something in this case. but by doing so you also neglect things. Many things. Of course anyone can choose to check whatever they wish. That does not change what *I* consider negligent. But neglecting is a necessity. Your view is reduced to a D specification to make statements about it in language theory where you check everything - and decide thereby to neglect everything else, below that. Including the buggy implementation of that spec running on a buggy OS on buggy hardware. In this context: It is one thing to be negligent (and I explicitly do not claim *not* to be negligent myself), but something completely different to pretend that being negligent is OK. It's not only ok. It's a necessity. The necessity of a limited being in an infinite universe. We can only hope to not neglect the important things - and trust in others is one way to increase the number of things we have hope to be ok. Making things @safe instead of only @trusted is another way. Both increase the view we have largely. But trying to check everything yourself is still in vain.
Re: [Semi-OT] to!string(enumType)
On Friday, 19 May 2017 at 21:04:24 UTC, Stefan Koch wrote: If a template does trigger a static assert, that static assert is ignored if there is another template in the overload set that could match. Wow. Didn't know that. Is this really part of the D grammar? Sometimes D is soo cool. Still - too cool for me to see this. I don't like templates looking similar and even taking the same types but the compiler does something too intelligent to avoid an ambiguity. And it's not visible from the API or documentation - you need to look into the source to disambiguate - I'm not convinced and still consider this bad style.
Re: Fantastic exchange from DConf
On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote: On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes Scherkl wrote: You cannot promise to the compiler that the code is memory safe since you have no knowledge of what it actually does. No. @trusted is about trust: you cannot rely on the compiler to verify it, but the code is reviewed by humans. Precisely. It is about trust the compiler extends to you, the programmer, instead of a mechanical proof (@safe): "Trusted functions are guaranteed by the programmer to not exhibit any undefined behavior if called by a safe function. Generally, trusted functions should be kept small so that they are easier to manually verify." [1] I take this to mean the programmer who wrote the library, not every user of the library. Ok, it's better the more people checked it but it need not be always me. Hm - we should have some mechanism to add to some list of people who already trust the code because they checked it. If you write an application that uses @trusted code - even from a third party library - *you* are the programmer that the compiler extends the trust to. This is not my point of view. Especially if I had payed for some library, even legally it's not my fault if it fails. For public domain ok, the end user is theoretically responsible for everything that goes wrong but even there nobody can check everything or even a relevant portion of it. Trust, but verify: Considering the damages already caused via memory corruption, I would argue that even if you have a list of people you trust to both write @trusted and review @trusted code (both of which is fine imho), reviewing them yourself (when writing an application) is the prudent (and sane) course of action. This is infeasable even if @safe and @trusted reduce the Herculic task by large. Especially basic libraries will over time become tested and audited by very many people or even organizations. So after some time they really can be trusted. Absolutely not. This kind of mentality is what allowed bugs like heartbleed to rot for years[2], or even decades[3]. Unsafe code can never be *inherently* trusted. In addition to trusted, D has unittests that - in harsh contrast to C - are run by most users. And especially @trusted functions have extensive tests - even more so if they ever showed some untrustworthy behaviour. This increasing unittest blocks make older and more used libraries indeed more reliable, even if a function is changed (also in contrast to C where a changed function start again at zero trust while a D function has to pass all the old unittests and therefore start with high trust level) For bigger projects you always need to trust in some previous work. Not really. You can always verify any @trusted code (and if the amount of @trusted code you have to verify is large, then I argue that you are using the wrong previous work with regards to memory safety). Sorry. Reviewing everything you use is impossible. I just can't believe you if you claim to do so. But having the @trusted and @save mechanism makes the resulting code a whole lot more trustworthy than any C library can ever be - just by reducing the number of lines of code that really need be audited. I agree with that viewpoint (and wrote about the reduced auditing work previously in this conversation), but the quote you responded to here was about using D in general being memory safe (which is binary "yes/no"), not any particular library's degree of trustworthyness with regards to memory safety (which is a continuous scale). No. Declaring a function @safe is still no binary "yes". I don't believe in such absolute values. Clearly the likelyhood of memory corruption will be orders of magnitude lower, but never zero. The compiler may have bugs, the system a SW is running on will have bugs, even hardware failures are possible. Everything is about trust. I personally would not going bejond probing some few functions within a library which I think are more complicated and fragile, and if I find them ok, my trust in what else the authors have marked @trusted increases likewise. That is your choice, but the general track record of trusting others to get it right without verifying it yourself remains atrocious and I would still consider you negligent for doing so, because while in C one has had little other choice historically - since without a @safe concept the amount of code one would have to verify reaches gargantuan size - in D we can (and should imho) only have small amounts of @trusted code. Of course. And an decreasing amount. But what we have is already a huge step in the right direction. We should live in the reality. Everybodies time is spare. So you can always spent your time for checking code only for the parts which are most important for you and which you suspect the most. Claiming otherwise is - believe it or not - making you less trustworthy to
Re: [Semi-OT] to!string(enumType)
On Friday, 19 May 2017 at 17:47:42 UTC, Stefan Koch wrote:
On Friday, 19 May 2017 at 17:34:28 UTC, Dominikus Dittes
Scherkl wrote:
On Friday, 19 May 2017 at 00:14:05 UTC, Stefan Koch wrote:
string enumToString(E)(E v)
{
static assert(is(E == enum),
"emumToString is only meant for enums");
Why that assert? We can check it at compiletime. Doesn't this
cry for a constraint? I would use asserts only ever for stuff
that's only known at runtime.
string enumToString(E)(E v) if(is(E == enum))
{
...
}
the static assert tells what's going on.
It it does result in a simple overload not found.
Hm. Maybe in this case it's ok, because enum is pretty much all
that can be expected as argument to "enumToString". But normally
I would calling not using a constraint "stealing overload
possibilities", because it would not be possible to overload the
same function for a different type if you use this kind of assert.
And the error message is not really better.
Re: [Semi-OT] to!string(enumType)
On Friday, 19 May 2017 at 00:14:05 UTC, Stefan Koch wrote:
string enumToString(E)(E v)
{
static assert(is(E == enum),
"emumToString is only meant for enums");
Why that assert? We can check it at compiletime. Doesn't this cry
for a constraint? I would use asserts only ever for stuff that's
only known at runtime.
string enumToString(E)(E v) if(is(E == enum))
{
...
}
Re: Fantastic exchange from DConf
On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote: On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer I don't expect people to use Phobos and audit all the @trusted blocks personally. As long as they don't actually call them, that's reasonable. But if your application ends up calling @trusted code and you did not audit that @trusted yourself, you have violated the @trusted requirement: You cannot promise to the compiler that the code is memory safe since you have no knowledge of what it actually does. No. @trusted is about trust: you cannot rely on the compiler to verify it, but the code is reviewed by humans. So there is a list of reviewers and if this list contains some names you happen to trust (sic!) you don't have to audit the code yourself. Especially basic libraries will over time become tested and audited by very many people or even organizations. So after some time they really can be trusted. If "D is memory safe" means "D is memory safe ONLY if you verify all of the standard library personally", we still have lost. It is more like "D is memory safe" meaning "D is memory safe ONLY if you verify all of the @trusted code your application end up compiling in / linking against". There is no way around that I can see without getting rid of @trusted, which is impossible for a systems PL. For bigger projects you always need to trust in some previous work. But having the @trusted and @save mechanism makes the resulting code a whole lot more trustworthy than any C library can ever be - just by reducing the number of lines of code that really need be audited. I personally would not going bejond probing some few functions within a library which I think are more complicated and fragile, and if I find them ok, my trust in what else the authors have marked @trusted increases likewise.
Re: Replacing std.math raw pointer arithmetic with a union type
On Wednesday, 17 May 2017 at 20:25:26 UTC, Stefan Koch wrote: On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote: On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote: the special case it supports if cast(uint*) and cast(ulong*) What about casting from real* when real.sizeof > double.sizeof? unsupported. The code in ctfeExpr (paintFloatInt) explicitly checks for size == 4 || size == 8 we finally need support for ucent!
Re: Invitation to review new DIP PR
On Monday, 15 May 2017 at 06:03:27 UTC, Mike Parker wrote: There's a PR for a new DIP titled "Delegatable Functions" [1]. If you have time, I invite you to review the PR to make sure it's in the best state possible for moving forward to a merge and preliminary review. At this stage, we're looking for copy edits (grammar, spelling, vocabulary), line edits (rephrasing sentences, restructuring paragraphs) and content (are there any major holes in the proposal, unanswered questions). Thanks in advance to any and all who participate. [1] https://github.com/dlang/DIPs/pull/61 Looks good to me.
Re: NetBSD amd64: which way is the best for supporting 80 bits real/double?
On Thursday, 11 May 2017 at 10:07:32 UTC, Joakim wrote: On Thursday, 11 May 2017 at 02:05:11 UTC, Nikolay wrote: I am porting LDC to NetBSD amd64, and I ask advice how to handle real type. NetBSD has limited support for this type. What is long double on NetBSD/amd64, 64-bit or full 80-bit? We were talking about this when I was porting to Android/x86, where long double is 64-bit but the FPU should support 80-bit. Iain suggested just sticking to the ABI, ie using 64-bit if that's how long double is defined (see next three comments after linked comment): https://github.com/dlang/phobos/pull/2150#issuecomment-42731651 This type exists, but standard library does not provide full set of math functions for it (e.g. sinus, cosinus, and etc). Currently I just forward all function calls to 64 bits version counterparts, but in this case a set of unit tests are failing. I see following approaches to handle this issue: - Totally remove 80 bit real type from NetBSD port (make real==double) - Change tests and skip asserts for NetBSD There is one additional approach: implement these functions in druntime, but it is too big/massive work for me. I wouldn't worry about it too much. If someone really needs this, they will have to chip in. Dmd uses compiler intrinsics for those trig functions, and I notice that they seem to just call the native x86 asm instructions: I hate it if D doesn't fully support the hardware just to be compatible to some bad designed C library. Hey, it's a system language! I want to be able to use the hardware I have to its fullest! And for calling C functions you always have to fing the fitting D-type by checking "mantdig" and map accordingly. Thats really not so difficult.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 28 April 2017 at 13:19:47 UTC, Chris wrote: On Thursday, 27 April 2017 at 12:29:48 UTC, Steven Schveighoffer wrote: On 4/24/17 1:43 AM, Nick Sabalausky (Abscissa) wrote: "Dashing, awesome, ultra-attractive programmer with an impeccably fine taste in languages." It's a bit long and doesn't include the letter D FIFY -Steve D-veloper. Yeah, I suggested that 4 days ago, but got no responses. So it seems nobody is pleased with this term :-(
Re: DIP 1007 Preliminary Review Round 1
On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote: DIP 1007 is titled "'future symbol' Compiler Concept". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md +1 I like the idea of beeing warned about new symbols in libraries, so that I can change my symbols ahead.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I would prefer D'veloper.
Re: Ordering comparisons
On Tuesday, 7 March 2017 at 02:51:37 UTC, Jonathan M Davis wrote: If we can, we should probably make structs that have opCmp use opCmp like they should, and those that don't continue to use memcmp for the moment but get a deprecation message. Then after whatever amount of time we think is appropriate, we disable the comparisons. So, we don't break anything immediately, but ultimately end up with the correct situation of comparisons not working unless opCmp being defined. +1 This is the only sensible approach.
Re: Returning the address of a reference return value in @safe code - 2.072 regression?
On Monday, 20 February 2017 at 21:05:17 UTC, Jack Stouffer wrote: On Monday, 20 February 2017 at 20:54:31 UTC, Jack Stouffer wrote: On Monday, 20 February 2017 at 20:49:43 UTC, Johan Engelen wrote: ... Yeah, this is another regression caused by DIP1000. Christ. For the record, the current list of regressions caused by DIP1000 https://issues.dlang.org/show_bug.cgi?id=17213 https://issues.dlang.org/show_bug.cgi?id=17188 https://issues.dlang.org/show_bug.cgi?id=17123 https://issues.dlang.org/show_bug.cgi?id=17117 17117 and 17123 are already fixed on HEAD, no? So only two regressions remaining - I hope DIP1000 can be used to build new container libraries soon.
Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath
On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: Range remove [...] But there's another issue here. remove() has other overloads: [...] Two constraints are common to all three, those are the only ones that actually need to be in the constraint. The others can go in the body under `static if`, as the user need not be concerned with them. This is a general issue in Phobos that too many constraints are user-facing when they don't need to be. This! Getting rid of overloads and at the same time simplify the constraints by moving them in the function with static if! That would really improve the function signatures!
Re: A New Import Idiom`
On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post describing the import idiom that came to light in a recent forum discussion regarding DIP 1005 [3]. The relevant links are at [1] and [2]. [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/ [2] https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ [3] https://forum.dlang.org/thread/tzqzmqhankrkbrfsr...@forum.dlang.org?page=1 Thanks for writing this up, Daniel. Has become quite a nice article.
Re: Have some down time at the year's end?
On Friday, 10 February 2017 at 17:15:12 UTC, Dominikus Dittes Scherkl wrote: Hmm. For me seems like you got some comments on your PR but didn't answer. Seems plausible not to include such PR. Ah, you received those answers just now, not at that time. Sorry.
Re: Have some down time at the year's end?
On Friday, 10 February 2017 at 14:36:31 UTC, Nemanja Boric wrote: On Friday, 10 February 2017 at 02:42:10 UTC, Andrei Alexandrescu wrote: On 02/09/2017 05:03 PM, Daniel Kozak wrote: Is this still accurate? I mean if I change some issue to "trivial", is there any process which will notify you or your students about it? Or are they actively watch this list? There is no automation. Thanks! -- Andrei Speaking of the recent discussion of abandoned trivial PRs, here's the one I submitted PR for, but got 0 attention: https://github.com/dlang/druntime/pull/1675 https://issues.dlang.org/show_bug.cgi?id=16470 Hmm. For me seems like you got some comments on your PR but didn't answer. Seems plausible not to include such PR.
Re: Workaround for DIP 1005
On Friday, 10 February 2017 at 13:28:43 UTC, Dominikus Dittes
Scherkl wrote:
Sorry, accidentally hit some key-combination that immediately
send the message that was not yet complete.
With my original proposal you would write
auto foo(foo.SysTime st1,
foo.SysTime st2,
foo.Duration d)
{
import std.datetime;
alias SysTime = std.datetime.SysTime;
alias Duration = std.datetime.Duration;
}
And the implementation of DIP1005 would only "create this alias
automatically", so that you would write what you always did - if
any type in a declaration is not found, the compiler tries to
find it in the function definition and use that instead.
Therefore I would call this "auto aliasing"
It does not inquire a (visible) language change, only an enhanced
lookup within the compiler.
Re: Workaround for DIP 1005
On Thursday, 9 February 2017 at 05:40:01 UTC, Jonathan M Davis
wrote:
On Friday, February 03, 2017 14:43:01 Dominikus Dittes Scherkl
via Digitalmars-d wrote:
Any thoughts?
This is really cool, but I have a couple of concerns about this
and how it seems deficient in comparison to DIP 1005.
Of course. This is why I called it a "workaround".
But in fact I would prefer to only use local imports instead of
some impoting template. But with this workaround in mind, the
implementation of DIP1005 would be much easier (see below).
[...]
The other problem is how much more verbose it is. With DIP
1005, you can do
with(import std.datetime)
auto foo(SysTime st1, SysTime st2, Duration d);
The import is only listed once, whereas with this technique,
you have to list it for each symbol. e.g.
auto foo(from!"std.datetime".SysTime st1,
from!"std.datetime".SysTime st2,
from!"std.datetime".Duration d);
With my original proposal you would write
auto foo(foo.M.SysTime st1,
foo.M.SysTime st2,
foo.M.Duration d)
{
import std.datetime;
}
Re: Name That Technique!
On Monday, 6 February 2017 at 09:00:43 UTC, Mike Parker wrote: On Monday, 6 February 2017 at 08:45:45 UTC, Dominikus Dittes Scherkl wrote: But is this really worth an article? IMO, as something targeted at non-D users, yes. Oh yeah? For bragging about how D uses modules and doesn't need global imports at all? This is not my style and I didn't feel that not needing global imports is something to brag about - they are useful as an overview. But with this new idiom .di-files are even more useless now - or really need to declare all the local imports to replace the lost overview. A brief overview of D's module system, a description of the problem & how the DIP was brought up to address it, But I'm not an expert for this. Especially I was not aware of any problem and even didn't liked the DIP. how the DIP was made irrelevant by the usage of features every D programmer knows but so many failed to realize could be used in this way... Ok, this is the most interesting part. This is what having an idea is all about. Find new ways to put the things already there together. But hard to describe. Maybe I'll give it a try.
Re: The extent of trust in errors and error handling
On Monday, 6 February 2017 at 06:08:22 UTC, Chris Wright wrote: On Sat, 04 Feb 2017 23:48:48 -0800, Ali Çehreli wrote: What I and many others who say Errors should not be caught are saying is, once the program is in an unexpected state, attempting to do anything further is wishful thinking. I've been thinking about this a bit more, and I'm curious: how do you recommend that an application behave when an Error is thrown? It has lost its face and shall commit sucide. That's the japanese way, and it has its merits. Continuing to work and pretend nothing has happened (the european way) makes it just untrustworthy from the begining. May be this is better for humans (they are untrustworthy anyway until some validation has been run on them), but for programs I prefer the japanese way.
Re: Name That Technique!
On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote: On 2/3/2017 11:14 AM, Andrei Alexandrescu wrote: On 2/3/17 10:41 AM, Daniel N wrote: On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Any thoughts? I like it! Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no language change at all. Congratulations! I agree, it's pretty dazz! We need to give this technique a memorable name (not an acronym). I thought "Voldemort Types" turned out rather well, whereas CTFE is klunky, UFCS is even worse. The absolute worst is C++ SFINAE. Any ideas? Scherkl-Nielsen Lookup? The perfect bikeshedding moment! Daniel, Dominikus: please consider writing an article about this. Thank you all that you like the idea. I found myself using this idiom quite some time now in my libraries but only recently realized, that it is the reason why I didn't found DIP1005 too compelling - I just didn't need it because of my workaround. So I thought I should share the idea - and Daniels extension makes it much easier to use. Have to update my libs with that :-) But is this really worth an article?
Re: Workaround for DIP 1005
On Friday, 3 February 2017 at 14:59:09 UTC, rikki cattermole wrote: On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. But this can already be worked around with some nice trick: Any thoughts? Needless syntax sugar: ?!? What is syntactic sugar? I did NOT propose any new syntax - my workaround already works with the current D language. In fact I think DIP1005 is syntactic sugar (maybe even "needless").
Workaround for DIP 1005
DIP 1005 provides new syntax to make it possible to avoid global
imports.
Till now global imports are necessary if a function uses types
declared in some imported module within it's declaration or
definition (otherwise a local import will do).
But this can already be worked around with some nice trick:
import someModule.SomeType;
SomeType fun()
{
...
}
can be replaced by:
fun.ST fun()
{
import someModule.SomeType;
alias ST = SomeType;
...
}
The same strategy works with types used in parameters or
constraints, of course.
Any thoughts?
Re: vibe.d 0.8.0 and 0.7.31 beta releases
On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote: Is it possible to have non-@safe callbacks be part of the non-deprecated API? Why? A @safe API allows you to use it within @safe code, but it doesn't require you to also write @safe code. Especially if you don't like to annotate your code to be @safe, even if you think it is safe, this doesn't hinders you to use other peoples @safe code. Only the reverse is a problem (other people, who like to annotate their code @safe, can't use your code if it is not annotated - so they start to ignore your code even if it would be @safe only because you don't bother).
Re: Need a std::numeric_limits::lowest() equivalent
On Saturday, 21 January 2017 at 15:55:35 UTC, Xavier Bigand wrote:
I don't see any other use case than for initialized maths
struct to an invalid state, and because it is generally in
template that working with integers and floats it is easier to
have same properties (when it have the same meaning).
I use
/// consider T.max to be NaN of unsigned types
/// and T.min to be NaN of signed types
@property bool isNaN(T)(const(T) x) pure @safe @nogc nothrow
if(isIntegral!T)
{
static if(isSigned!T)
return x == T.min;
else // unsigned
return x == T.max;
}
/// add a property to numeric types that can be used as return
value if a result is out of bounds
template invalid(T) if(isNumeric!T)
{
static if(isFloatingPoint!T)
@property enum invalid = T.init;
else static if(isSigned!T)
@property enum invalid = T.min; // 0x80..00
else // unsigned
@property enum invalid = T.max; // 0xFF..FF
}
/// returns the save (not invalid) minimum value for the given
type
template smin(T) if(isNumeric!T)
{
static if(isFloatingPoint!T)
@property enum smin = -T.max; // T.min is the smallest
representable positive value!!
else static if(isSigned!T)
@property enum smin = T(T.min+1);
else // unsigned
@property enum smin = T.min; // 0
}
/// returns the save (not invalid) maximum value for the given
type
template smax(T) if(isNumeric!T)
{
static if(isUnsigned!T)
@property enum smax = T(T.max-1u);
else
@property enum smax = T.max;
}
Re: Catching Errors
On Thursday, 19 January 2017 at 14:29:46 UTC, Jack Stouffer wrote: From what I understand, the difference between an Exception and and Error is that Errors signal your program has entered into an invalid state. For example, going past the end of an array and attempting to access that memory. On the flip side, Exceptions signal that something out of the ordinary happened, but with proper handling the program can go on it's merry way. An example being entering 13 as a month in a std.datetime.Date. If this is the case, would it not make sense to make it illegal to catch Errors in @safe code? I would say yes. This sounds plausible.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Tuesday, 3 January 2017 at 12:57:22 UTC, Andrei Alexandrescu wrote: On 01/03/2017 02:19 AM, Dominikus Dittes Scherkl wrote: On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: DIP1005 gives consideration to the speed of compilation aspect in larger proportion than speed's importance; the first and foremost benefit of DIP1005 is it closes the gap on dependency encapsulation, which had been very successfully narrowed by local imports. I love that idea. But I still can't see why this requires any new syntax. Simply extending the scope of local inports to include the function header is enough. I'll mention this possibility in the DIP. Good. Only for .di-generation it may be useful to move all local imports to the declaration (maybe with this new syntax "with" before it) - but that should be done with ALL local imports, because today the .di-files are incomplete and will stay so if the new syntax is introduced but "old-style" local imports still valid and not exported to the .di. Or the old local imports become deprecated together with the introduction of the new "with" syntax and vanish soon after that. Local imports don't pertain to the interface, they are an implementation detail. Why would those be made a part of the .di? .di are needed to ship with a library. If a function locally imports some type, the library is dependant on that import, so if I want to use the library, I have to install all stuff it depends on too. And to find out, what exactly the library depends on the .di is the place I look, so there need to be mentioned each and every import - no matter how deeply local that may be. If that is not the case it renders .di-files completely useless to me (as they are at the moment), because I need to find out the dependencies somewhere else (e.g. in some documentation of the library). While it is likely that the dependencies of a library may be documented somewhere, this is not guaranteed. But .di-files are guaranteed to ship with a lib because else it cannot link - at least if it contains any templates, which is about 100% sure for a language like D. So I would like to see local imports in the .di-file, even if they are not strictly needed to compile because the imported types are not exposed in the function signature.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote: DIP1005 gives consideration to the speed of compilation aspect in larger proportion than speed's importance; the first and foremost benefit of DIP1005 is it closes the gap on dependency encapsulation, which had been very successfully narrowed by local imports. I love that idea. But I still can't see why this requires any new syntax. Simply extending the scope of local inports to include the function header is enough. Only for .di-generation it may be useful to move all local imports to the declaration (maybe with this new syntax "with" before it) - but that should be done with ALL local imports, because today the .di-files are incomplete and will stay so if the new syntax is introduced but "old-style" local imports still valid and not exported to the .di. Or the old local imports become deprecated together with the introduction of the new "with" syntax and vanish soon after that.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Friday, 16 December 2016 at 07:15:51 UTC, Walter Bright wrote: On 12/15/2016 9:07 AM, Dominikus Dittes Scherkl wrote: So, I no longer propose to change nothing except the internal compiler behaviour. Now I propose to additionally change the .di-file generation to also add all local imports to the start of the declaration file, so that having this file gives ALL dependencies of the declared stuff. That will subtly change the behavior of overloads across module lookups. Hm. Maybe if the .di-file would be used for code generation. But does that make sense? A .di-file is delivered together with an already compiled library to provide the sources of templates AND to show up all dependencies of the library, no? Both for the interested reader and the compiler. And the actual .di-files doesn't do that correct.
Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback
On Thursday, 15 December 2016 at 16:16:51 UTC, Walter Bright
wrote:
On 12/14/2016 5:26 AM, Dominikus Dittes Scherkl wrote:
Why not leave it as it is and only change the compiler to
perform inputs _within_ a function before evaluating the
declaration, so that
the symbols imported can be used in the declaration?
e.g.
fun(Range x) if(isInputRange!x)
{
import std.range;
auto a = x.front();
}
That would make it problematic to have function declarations.
Yeah, but declarations ARE already problematic, because local
imports are not visible from them, so only having a declaration
file (.di) at the moment already is not enough to determine the
dependencies.
And as I understand you, you don't plan to remove the local
imports as they are now? (would be a really huge breaking change!)
So, I no longer propose to change nothing except the internal
compiler behaviour.
Now I propose to additionally change the .di-file generation to
also add all local imports to the start of the declaration file,
so that having this file gives ALL dependencies of the declared
stuff.
Re: Compiling to shared library with static dependencies
On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote: Any ideas what to do or how to proceed? Thanks a bunch! This kind of questions is better adressed to the "Learn" forum.
