[Issue 9186] Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186 --- Comment #3 from Kenji Hara 2012-12-21 00:30:27 PST --- This is not a type system problem. All manifest constants, which declared by `enum` and T.init, make literal expressions in the places where they used. alias T = string[]; enum T strs = [[]]; foo(T.init); // same as foo(null); foo(strs);// same as foo([[]]); And, empty array literal and null literal can ignore their type qualifiers in constant-folding process, because they have no references to qualified values. (From the view of compiler development, it is mainly designed by Expression::implicitConvTo.) I can agree that the behavior is not intuitive, but I'm not sure what is the correct behavior... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9186] Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186 Max Samukha changed: What|Removed |Added CC||samu...@voliacable.com --- Comment #4 from Max Samukha 2012-12-21 01:35:54 PST --- (In reply to comment #3) > I'm not sure what is the correct behavior... Obviously, the correct behavior is to preserve the type information. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9186] Manifest constant can violate const correctness restrictions when empty
http://d.puremagic.com/issues/show_bug.cgi?id=9186 --- Comment #5 from monarchdo...@gmail.com 2012-12-21 01:52:11 PST --- (In reply to comment #3) > This is not a type system problem. > > All manifest constants, which declared by `enum` and T.init, make literal > expressions in the places where they used. > > alias T = string[]; > enum T strs = [[]]; > foo(T.init); // same as foo(null); > foo(strs);// same as foo([[]]); > > And, empty array literal and null literal can ignore their type qualifiers in > constant-folding process, because they have no references to qualified values. I see your point, but I argue there is a difference between a "type-less" literal and an "empty" literal. (T[]).init, while empty, does carry a type, and it should be preserved/propagated. Heck, proof that a non-empty literal can have "no type": "[[]]" is *not* empty. It is a type-less slice which carries a single empty typeless slice. Yet you can still write "int[][] a = [[]];" -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #2 from Andrej Mitrovic 2012-12-21 06:37:34 PST --- @bear: Please see the comments here: https://github.com/D-Programming-Language/phobos/pull/1017 The feature can be implemented but to!() was rejected, so we need to come up with some alternative function names and put them somewhere other than std.conv. Personally I don't see how people will be expected to find an obscure function name like 'codePointIdx'. This isn't related unicode representation at all, there should be no confusion with Unicode when it comes to representing 0-9, it's always the same regardless of encoding. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #3 from monarchdo...@gmail.com 2012-12-21 06:58:42 PST --- (In reply to comment #2) > @bear: Please see the comments here: > https://github.com/D-Programming-Language/phobos/pull/1017 > > The feature can be implemented but to!() was rejected, so we need to come up > with some alternative function names and put them somewhere other than > std.conv. > > Personally I don't see how people will be expected to find an obscure function > name like 'codePointIdx'. This isn't related unicode representation at all, > there should be no confusion with Unicode when it comes to representing 0-9, > it's always the same regardless of encoding. Well, that's why we have std.ascii, no? For all char operations when we don't care about unicode. In all fairness, unicode defines "is numeric" (which we already have) and "numeric value" (which we *should* have). C# and java both implement the methods "getNumericValue". Java even implements one taking chars, and another taking int (dchar) http://msdn.microsoft.com/en-us/library/system.char.getnumericvalue.aspx http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Character.html I'd say we should just add: std.ascii.getNumericValue std.uni.getNumericValue (or plain numericValue) I already wrote the ascii version (easy as pie), and support for the [Nd] group, using a binary search, followed by an offset from the lower bound. [Nl] and [Po] require a straight up mapping of codepoint to value, but I'm still writing the parser that extract the data for the raw UCD (http://www.unicode.org/Public/6.2.0/ucdxml/). The file is too large for std.xml to handle, so it's back to C++ for me :/ The only questions I have is: Return value: int or double? Input is not numeric: -1 or exception? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9192] New: Allow opEquals for .tupleof expressions
http://d.puremagic.com/issues/show_bug.cgi?id=9192
Summary: Allow opEquals for .tupleof expressions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2012-12-21
07:02:39 PST ---
struct S
{
this(S rhs)
{
this.tupleof = rhs.tupleof;
}
bool opEquals(const ref S rhs) const
{
return this.tupleof == rhs.tupleof;
}
int x;
}
void main()
{
S s1, s2;
assert(s1 == s2);
}
test.d(12): Error: incompatible types for ((tuple(this.x)) == (tuple(rhs.x))):
'(const(int))' and '(const(int))'
Since we're allowed to assign to a .tupleof, why not allow comparisons? For one
use-case this would make it easy to implement a workaround until Issue 3789 is
fixed.
Although only the == and != should probably be implemented, < and > don't make
much sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #4 from Andrej Mitrovic 2012-12-21 07:08:12 PST --- (In reply to comment #3) > Well, that's why we have std.ascii, no? For all char operations when we don't > care about unicode. > > In all fairness, unicode defines "is numeric" (which we already have) and > "numeric value" (which we *should* have). Damn Unicode, why does it need to have 10 different ways to represent something? :) > The only questions I have is: > Return value: int or double? int, because int is implicitly convertible to double, not vice-versa. At least for the ascii part, if Unicode has code points that represent floating-point values.. then I really don't understand what Unicode is about anymore. > Input is not numeric: -1 or exception? Hmm.. although exceptions are preferred I think for performance reasons we might consider using -1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #5 from Dmitry Olshansky 2012-12-21 07:17:53 PST --- >Java even implements > one taking chars, and another taking int (dchar) That's because Java folks used to have only 16bit chars. Now true codepoints are going in form of 'int'. > http://msdn.microsoft.com/en-us/library/system.char.getnumericvalue.aspx > http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Character.html > > I'd say we should just add: > std.ascii.getNumericValue > std.uni.getNumericValue > (or plain numericValue) > Agreed and the name should be numericValue. > I already wrote the ascii version (easy as pie), and support for the [Nd] > group, using a binary search, followed by an offset from the lower bound. > > [Nl] and [Po] require a straight up mapping of codepoint to value, but I'm > still writing the parser that extract the data for the raw UCD > (http://www.unicode.org/Public/6.2.0/ucdxml/). > I'm wrapping up a revamp of std.uni that makes it piece of cake to create character sets. And maps are converted to multi-staged tables that are faster the binary search on a large set. I'd suggest to wait a bit on it (so as to not duplicate work) and introduce only std.ascii version as the most useful. The ongoing polishing, fixing and testing against ICU is going on here: https://github.com/blackwhale/gsoc-bench-2012 > The file is too large for std.xml to handle, so it's back to C++ for me :/ > http://www.unicode.org/Public/UNIDATA/UnicodeData.txt Same thing but no useless XML trash. Description of fields is somewhere in the middle of this document http://www.unicode.org/reports/tr44/ > The only questions I have is: > Return value: int or double? Should be rational to acurately represent things like "1/5" character ;) I do suspect some simple custom type could do (2 shorts packed in one struct etc.). > Input is not numeric: -1 or exception? -1 is fine I think as this rather low level (per character) and it's not at all convenient to throw (and then catch). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #6 from Andrej Mitrovic 2012-12-21 07:26:08 PST --- Ok I think there are two enhancements here, one for the simple ascii int->char, char->int, and the other more complicated Unicode implementation which monarch/dmitry know more about. I think we should split up the Unicode enhancement into a new bugzilla entry since the ASCII one can be implemented right now so this issue can be closed soon. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #7 from hst...@quickfur.ath.cx 2012-12-21 07:29:58 PST --- It would be nice to have a separate issue filed for tracking Unicode support progress. It can maybe include things like issue 9173 too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3756] std.traits.ReturnType broken for ref returns
http://d.puremagic.com/issues/show_bug.cgi?id=3756
Andrej Mitrovic changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||andrej.mitrov...@gmail.com
Resolution||FIXED
--- Comment #1 from Andrej Mitrovic 2012-12-21
07:30:46 PST ---
Type modifiers can't be passed around in the language, but I think there's a
separate issue already opened for this.
Anyway you can do:
import std.traits;
ref uint foo(ref uint num) {
return num;
}
void main()
{
alias FunctionAttribute FA;
static assert(functionAttributes!foo & FA.ref_);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #8 from Andrej Mitrovic 2012-12-21 07:32:31 PST --- (In reply to comment #7) > It would be nice to have a separate issue filed for tracking Unicode support > progress. It can maybe include things like issue 9173 too. Reporters could add "Unicode" into the Keywords box for these types of issues so we can filter them out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543
--- Comment #9 from monarchdo...@gmail.com 2012-12-21 07:34:14 PST ---
> Ok I think there are two enhancements here, one for the simple ascii
> int->char,
> char->int, and the other more complicated Unicode implementation which
> monarch/dmitry know more about.
>
> I think we should split up the Unicode enhancement into a new bugzilla entry
> since the ASCII one can be implemented right now so this issue can be closed
> soon.
I'm a bit too busy to do the actual pull, but I wrote code, doc and test for
this already.
//
/++
If $(D c) is an ASCII digit, returns the
corresponding numeric value. Returns -1 otherwise.
+/
int numericValue(dchar c) @safe pure nothrow
{
return ('0' <= c && c <= '9') ? (c - '0') : -1;
}
unittest
{
int counter = 0;
foreach (char c; 0 .. 80)
{
if (isDigit(c))
assert(numericValue(c) == counter++);
else
assert(numericValue(c) == -1);
}
}
//
Not much, but there is never any reason to do the same work twice...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9012] writef/format inconsistent with format specifier
http://d.puremagic.com/issues/show_bug.cgi?id=9012 --- Comment #4 from hst...@quickfur.ath.cx 2012-12-21 07:38:30 PST --- The pull has been merged; I just tested the code and it's working now. Should this bug be closed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4183] @property doesnt work with delegate return type
http://d.puremagic.com/issues/show_bug.cgi?id=4183 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #4 from hst...@quickfur.ath.cx 2012-12-21 07:41:39 PST --- Tested on latest dmd git head, seems to be working now. Should we close this bug? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4463] double.init in associative array seems 0.0
http://d.puremagic.com/issues/show_bug.cgi?id=4463 --- Comment #1 from hst...@quickfur.ath.cx 2012-12-21 07:45:21 PST --- Seems to be related to bug 3825. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #10 from monarchdo...@gmail.com 2012-12-21 07:53:36 PST --- (In reply to comment #5) > > I'm wrapping up a revamp of std.uni that makes it piece of cake to create > character sets. And maps are converted to multi-staged tables that are faster > the binary search on a large set. I'd suggest to wait a bit on it (so as to > not > duplicate work) and introduce only std.ascii version as the most useful. > > The ongoing polishing, fixing and testing against ICU is going on here: > https://github.com/blackwhale/gsoc-bench-2012 OK: The thing I was having trouble though is that existing binary search returns a bool, whereas I need the actual entry, so I can do "value - entry[0]", eg: // static immutable dchar[2][] table1 = [ [ 0x0030, 0x0039], // [ 0x0660, 0x0669], //ARABIC-INDIC [ 0x06F0, 0x06F9], //EXTENDED ARABIC-INDIC ... //--- That's because all the entries in [Nd] are consecutive numerals starting at 0. I can also cram a select couple of entries from [Nl] and [Po] that also use this scheme. So if I have the unicode 0x0665 (The ARABIC-INDIC numeral '6'), I'd want to find [ 0x0660, 0x0669], and then "return 0x0665 - 0x0660". Well, I don't need the entire pair, but at least the lhs of the pair. If you could keep that in mind during your re-write. Or not. Just throwing it out there. For all other entries in [Nl] and [Po], I'd have: static immutable dchar[2][] table1 = [ [ 0x261D, 100], //ROMAN NUMERAL ONE HUNDRED So that's just basic dictionary. But I don't think you can statically allocate an AA. So yeah, just throwing that your direction too. > > The file is too large for std.xml to handle, so it's back to C++ for me :/ > > > http://www.unicode.org/Public/UNIDATA/UnicodeData.txt > > Same thing but no useless XML trash. Description of fields is somewhere in the > middle of this document > http://www.unicode.org/reports/tr44/ Nice, TY. > > The only questions I have is: > > Return value: int or double? > > Should be rational to acurately represent things like "1/5" character ;) > I do suspect some simple custom type could do (2 shorts packed in one struct > etc.). > > > Input is not numeric: -1 or exception? > > -1 is fine I think as this rather low level (per character) and it's not at > all > convenient to throw (and then catch). The only issue I have with returning -1 is that it is a magic value. The fact that there is no unicode for -1 is pure coincidence, and not by design. In particular, any attempt to write "if (numericValue(c) < 0) fail" would also be wrong because: http://unicode.org/cldr/utility/character.jsp?a=0F33 The TIBETAN DIGIT HALF ZERO returns -0.5 Do we *really* want to standardize the syntax of "if (numericValue(c) < -0.7)" ? ... Damn you unicode! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #11 from Dmitry Olshansky 2012-12-21 08:00:56 PST --- (In reply to comment #10) > (In reply to comment #5) > > > > I'm wrapping up a revamp of std.uni that makes it piece of cake to create > > character sets. And maps are converted to multi-staged tables that are > > faster > > the binary search on a large set. I'd suggest to wait a bit on it (so as to > > not > > duplicate work) and introduce only std.ascii version as the most useful. > > > > The ongoing polishing, fixing and testing against ICU is going on here: > > https://github.com/blackwhale/gsoc-bench-2012 > > OK: The thing I was having trouble though is that existing binary search > returns a bool, whereas I need the actual entry, so I can do "value - > entry[0]", eg: > > // > static immutable dchar[2][] table1 = [ > [ 0x0030, 0x0039], // > [ 0x0660, 0x0669], //ARABIC-INDIC > [ 0x06F0, 0x06F9], //EXTENDED ARABIC-INDIC > > ... > //--- > That's because all the entries in [Nd] are consecutive numerals starting at 0. > I can also cram a select couple of entries from [Nl] and [Po] that also use > this scheme. > Sometimes I was able to abuse the natural format of data and sometimes failed. But what proved to be quite good is varying sizes of multi-staged rable to match "periods" of data. In the end if the data has a lot of common "rows" a multi-staged table of certain size per stage is bound hit a sweet spot. > So if I have the unicode 0x0665 (The ARABIC-INDIC numeral '6'), I'd want to > find [ 0x0660, 0x0669], and then "return 0x0665 - 0x0660". > > Well, I don't need the entire pair, but at least the lhs of the pair. > > If you could keep that in mind during your re-write. Or not. Just throwing it > out there. > > For all other entries in [Nl] and [Po], I'd have: > static immutable dchar[2][] table1 = [ > [ 0x261D, 100], //ROMAN NUMERAL ONE HUNDRED > > So that's just basic dictionary. But I don't think you can statically allocate > an AA. So yeah, just throwing that your direction too. > Well, AA is a fat pig w.r.t RAM usage. But thanks anyway. > > > The file is too large for std.xml to handle, so it's back to C++ for me :/ > > > > > http://www.unicode.org/Public/UNIDATA/UnicodeData.txt > > > > Same thing but no useless XML trash. Description of fields is somewhere in > > the > > middle of this document > > http://www.unicode.org/reports/tr44/ > > Nice, TY. > > > > The only questions I have is: > > > Return value: int or double? > > > > Should be rational to acurately represent things like "1/5" character ;) > > I do suspect some simple custom type could do (2 shorts packed in one struct > > etc.). > > > > > Input is not numeric: -1 or exception? > > > > -1 is fine I think as this rather low level (per character) and it's not at > > all > > convenient to throw (and then catch). > > The only issue I have with returning -1 is that it is a magic value. The fact > that there is no unicode for -1 is pure coincidence, and not by design. In > particular, any attempt to write "if (numericValue(c) < 0) fail" would also be > wrong because: > http://unicode.org/cldr/utility/character.jsp?a=0F33 > The TIBETAN DIGIT HALF ZERO returns -0.5 > > Do we *really* want to standardize the syntax of "if (numericValue(c) < -0.7)" > ? > > ... > > Damn you unicode! Aye, and given there are things like "1e12" I don't think packing it would work any better... some kind of custom type is required. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543
--- Comment #12 from Andrej Mitrovic 2012-12-21
08:04:19 PST ---
(In reply to comment #9)
> int numericValue(dchar c) @safe pure nothrow
What about int->dchar?
We could call it toNumericChar or something, but it would probably have to
throw on invalid input? Or can we also return -1? E.g.
char toNumericChar(int i) @safe pure nothrow
{
return cast(char)((0 <= i && i <= 9) ? (i + '0') : -1);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543
--- Comment #13 from monarchdo...@gmail.com 2012-12-21 08:08:20 PST ---
(In reply to comment #12)
> (In reply to comment #9)
> > int numericValue(dchar c) @safe pure nothrow
>
> What about int->dchar?
>
> We could call it toNumericChar or something, but it would probably have to
> throw on invalid input? Or can we also return -1? E.g.
>
> char toNumericChar(int i) @safe pure nothrow
> {
> return cast(char)((0 <= i && i <= 9) ? (i + '0') : -1);
> }
-1 is char.init, so seems good to me. Although I'd go and write it as
"char.init" explicitly in the code actually, so as to limit any possible
confusion.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4183] @property doesnt work with delegate return type
http://d.puremagic.com/issues/show_bug.cgi?id=4183 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andrej Mitrovic 2012-12-21 08:08:18 PST --- It's fixed in 2.060 too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #14 from monarchdo...@gmail.com 2012-12-21 08:11:21 PST --- (In reply to comment #11) > > Aye, and given there are things like "1e12" I don't think packing it would > work > any better... some kind of custom type is required. Really? According to: http://unicode.org/cldr/utility/properties.jsp?a=Numeric_Value#Numeric_Value They only go from -0.5 // TIBETAN DIGIT HALF ZERO to 1_000_000 // ROMAN NUMERAL ONE HUNDRED THOUSAND So I figured though we were in the number plane where there is a perfect "int <=> double" correlation. If this is not the case... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3714] Identity assignment operator overload LEGAL for const, shared, etc.
http://d.puremagic.com/issues/show_bug.cgi?id=3714 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #1 from Andrej Mitrovic 2012-12-21 09:08:34 PST --- Fixed in 2.061 git-head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3715] std.string.format can't use const/immutable toString functions
http://d.puremagic.com/issues/show_bug.cgi?id=3715 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #6 from Andrej Mitrovic 2012-12-21 09:09:38 PST --- Fixed in 2.060. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3810] overloading on const does not work for template methods
http://d.puremagic.com/issues/show_bug.cgi?id=3810 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED --- Comment #3 from Andrej Mitrovic 2012-12-21 09:13:03 PST --- Fixed in 2.060 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #15 from bearophile_h...@eml.cc 2012-12-21 09:54:26 PST --- Having functions in std.ascii (and elsewhere) seems acceptable. But I think the name of such functions shouldn't be too much long. to!int raises exceptions. Returning -1 in case of errors seems able to cause some problems. One common use case for the char->int conversion: auto s = "123x456"; auto digits = s.map!numericValue().array(); Now I have to scan digits again looking for any -1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #16 from Andrej Mitrovic 2012-12-21 10:10:37 PST --- (In reply to comment #15) > Having functions in std.ascii (and elsewhere) seems acceptable. But I think > the > name of such functions shouldn't be too much long. > > > to!int raises exceptions. Returning -1 in case of errors seems able to cause > some problems. One common use case for the char->int conversion: > > auto s = "123x456"; > auto digits = s.map!numericValue().array(); > > Now I have to scan digits again looking for any -1. *But* you can wrap it inside a function which throws on -1 (pseudocode): auto s = "123x456"; auto thr = (a) => a == -1 ? throw ConvException() : a; auto digits = s.map!numericValue().array(); Whereas if it threw to begin with you're forced to catch exceptions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3561] math.abs signature accepts static arrays, but errors internally.
http://d.puremagic.com/issues/show_bug.cgi?id=3561 Andrej Mitrovic changed: What|Removed |Added Keywords|diagnostic | CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-12-21 10:15:58 PST --- It doesn't error internally anymore. But I'm keeping it open for the enhancement request for static array support. Btw your patch doesn't seem to work for this test-case anymore: assert(abs([-1,-2,-3]) == [1,2,3]); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #17 from Dmitry Olshansky 2012-12-21 10:20:15 PST --- (In reply to comment #14) > (In reply to comment #11) > > > > Aye, and given there are things like "1e12" I don't think packing it would > > work > > any better... some kind of custom type is required. > > Really? According to: > > http://unicode.org/cldr/utility/properties.jsp?a=Numeric_Value#Numeric_Value > > They only go from > -0.5 // TIBETAN DIGIT HALF ZERO > to > 1_000_000 // ROMAN NUMERAL ONE HUNDRED THOUSAND > > So I figured though we were in the number plane where there is a perfect "int > <=> double" correlation. If this is not the case... You missed the nice and cool 1.0e12 ! http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AnumericValue%3D1.0E12%3A%5D&g= -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #18 from bearophile_h...@eml.cc 2012-12-21 10:24:12 PST --- (In reply to comment #16) > Whereas if it threw to begin with you're forced to catch exceptions. There is no perfect solution. Exceptions are safer than error codes because if you forget to test for a negative result, your program stops. On the other hand exceptions are less efficient, less handy to use in nothrow functions, and often require some try-catch wrapping. In this enhancement request I was originally asking for an overload of to!(), this means a solution that throws exceptions when the input is wrong. Efficiency is not a significant problem for me here because where I need to convert char digits to numerical digits with max efficientcy I use a '0' subtraction (or a vectorized version of it). So with this overload of to!() I was looking for safety. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com Version|D1 & D2 |D1 --- Comment #6 from Andrej Mitrovic 2012-12-21 10:39:11 PST --- I don't know the state of D1 but in D2 these overloads are flagged as errors, so I'm removing D2 from the list. As for non-virtual private/package - this should be an enhancement request, but it's probably been debated many times already (I personally believe access specifiers should not mess with the virtuality of a method). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3131] better type resolve
http://d.puremagic.com/issues/show_bug.cgi?id=3131 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #7 from Andrej Mitrovic 2012-12-21 10:46:48 PST --- (In reply to comment #6) > I would say they should both be allowed. The declaration of the struct member > should happen semantically after the type lookup, just like with the variable. This kind of code is just asking for trouble. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #19 from monarchdo...@gmail.com 2012-12-21 10:53:11 PST --- (In reply to comment #17) > (In reply to comment #14) > > (In reply to comment #11) > > > > > > Aye, and given there are things like "1e12" I don't think packing it > > > would work > > > any better... some kind of custom type is required. > > > > Really? According to: > > > > http://unicode.org/cldr/utility/properties.jsp?a=Numeric_Value#Numeric_Value > > > > They only go from > > -0.5 // TIBETAN DIGIT HALF ZERO > > to > > 1_000_000 // ROMAN NUMERAL ONE HUNDRED THOUSAND > > > > So I figured though we were in the number plane where there is a perfect > > "int > > <=> double" correlation. If this is not the case... > > You missed the nice and cool 1.0e12 ! > > http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3AnumericValue%3D1.0E12%3A%5D&g= Well, that still fits in both a long, and in a double with no loss, so we're still good. Crisis averted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5543] to!int to see a char as a single-char string
http://d.puremagic.com/issues/show_bug.cgi?id=5543 --- Comment #20 from monarchdo...@gmail.com 2012-12-21 10:55:24 PST --- (In reply to comment #18) > (In reply to comment #16) > > > Whereas if it threw to begin with you're forced to catch exceptions. > > There is no perfect solution. Exceptions are safer than error codes because if > you forget to test for a negative result, your program stops. On the other > hand > exceptions are less efficient, less handy to use in nothrow functions, and > often require some try-catch wrapping. > > In this enhancement request I was originally asking for an overload of to!(), > this means a solution that throws exceptions when the input is wrong. > > Efficiency is not a significant problem for me here because where I need to > convert char digits to numerical digits with max efficientcy I use a '0' > subtraction (or a vectorized version of it). So with this overload of to!() I > was looking for safety. I think a good solution is to accept having different semantics: std.ascii.numericValue: int numericValue(dchar c) safe nothrow pure; returns -1 on failure std.uni.numericValue: double numericValue(dchar c) safe pure; Throws on failure If you are doing anything with unicode, the exception's overhead will be mostly moot compared to the cost (I think). When operating with ASCII, then it's a different ballgame (IMO). That's my opinion anyways. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 --- Comment #7 from Diggory 2012-12-21 11:19:38 PST --- Andrej, that seems like a funny change to me. Unless D2 either allows virtual package functions or states that these are not allowed it seems that it's still broken to me. The spec says "All non-sta�tic non-pri�vate non-tem�plate mem�ber func�tions are vir�tual." which I interpret to include package members. Not that I particularly care any more... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #8 from Jonathan M Davis 2012-12-21 11:53:54 PST --- It's been discussed many times, and the spec is wrong in this case (I keep meaning to update it but haven't done so yet). public and protected member functions are _always_ virtual unless the compiler can determine that they're never overridden (which can only happen when they're final). private and package member functions are _never_ virtual. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 --- Comment #9 from Andrej Mitrovic 2012-12-21 15:09:12 PST --- (In reply to comment #7) > Yeah I know, the spec tells one thing on one page, then another thing on another. It says "Package extends private" on the protection attributes page, implying it's final like private. Small note: In terms of the compiler implementation, the private and package set to non-virtual boils down to a single `if` check in the front-end. Forcing private and package non-virtual must have a rationale in the spec. There isn't one, so Walter and Andrei should state exactly why this decision was made. Actually, Walter and Andrei obviously had a miscommunication, because Andrei expected private to allow being virtual in TDPL. And 'package' being non-virtual isn't mentioned in TDPL either (lots of people get confused by this). So maybe Walter is the one to write the rationale. I also believe it's not too late to change the state of things. We have the `final` keyword after all. Yes, making private and package virtual could potentially slow down code, but fixing it is trivial, it just requires a `final` keyword. Perhaps the the compiler can be made smart enough to optimize non-overriden private/package methods so they're made final. Maybe if -lib or -c are not used it can do such optimizations. It's ironic that the argument against private/package being virtual is because of performance reasons when we've already made the mistake of making all methods virtual by default. I *still* can't get used to the fact that a public method is virtual by default, it really lacks that documentation aspect of having a 'virtual' keyword right next to it. And as argumented before, you could easily forget to mark something as 'final' in a library, the user overriding such a method, followed by an API update where you do a bugfix and mark it as final, which ends up breaking the user code. Unfortunately this also becomes an argument against making private/package virtual by default too. Non-virtual by default + a virtual keyword + no limits on virtuality based on access specifiers => dream come true (for me). We're in an odd status-quo, all I can do is sigh at the situation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3438] struct ctor with defaulted parameters should be rejected
http://d.puremagic.com/issues/show_bug.cgi?id=3438 Andrej Mitrovic changed: What|Removed |Added Keywords|wrong-code |accepts-invalid, pull CC||andrej.mitrov...@gmail.com Platform|Other |All Version|2.000 |D2 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|constructor with defaulted |struct ctor with defaulted |parameters ignored |parameters should be ||rejected OS/Version|Linux |All --- Comment #4 from Andrej Mitrovic 2012-12-21 15:52:48 PST --- Changed what was basically an enhancement request into an accepts-invalid bug. If the state of things change we can work on it later (if Walter green-lights default ctors for structs), but for now all forms of default ctors in structs must be rejected by the compiler. https://github.com/D-Programming-Language/dmd/pull/1397 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 --- Comment #10 from Andrej Mitrovic 2012-12-21 17:04:28 PST --- (In reply to comment #9) > Non-virtual by default + a virtual keyword + no limits on virtuality based on > access specifiers => dream come true (for me). I forgot one thing that completes the circle, and that is friend declarations. That way private inheritance actually becomes useful beyond the module the class is declared in. I never liked the idea of having private leak into the entire module to begin with, I want fine-grained access via friend declarations and access specifiers which don't mess with virtuality. Otherwise I'm left using PIMPL idioms or mixin templates (yuck!). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3258] Calling private or package override methods calls the base implementation
http://d.puremagic.com/issues/show_bug.cgi?id=3258 --- Comment #11 from Stewart Gordon 2012-12-21 17:14:10 PST --- (In reply to comment #10) > I forgot one thing that completes the circle, and that is friend declarations. There are no friend declarations in D. So what exactly are you talking about? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4006] dirEntries won't span subdirectories
http://d.puremagic.com/issues/show_bug.cgi?id=4006 Vladimir Panteleev changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||thecybersha...@gmail.com Resolution||WORKSFORME --- Comment #3 from Vladimir Panteleev 2012-12-21 21:20:05 PST --- Works on Linux in DMD 2.060. Is expected to fail on Windows per Dmitry's comment. OP did not specify platform... Closing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8967] dirEntries throws when encountering a "long path" on windows
http://d.puremagic.com/issues/show_bug.cgi?id=8967 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev 2012-12-21 21:24:30 PST --- I'm not sure whether the standard library should be adding the \\?\ prefix internally. If we are to change dirEntries, then we should also change all I/O routines that deal with paths. And even then, the resulting paths may not be usable by other components (used directly in the user's program), such as OS or C functions, and external programs. To work around this problem, the user could also use a function such as the one here [1], and pass path strings through it at the point where they enter the program's I/O logic layer. [1]: https://github.com/CyberShadow/RABCDAsm/blob/master/common.d#L25 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8298] dirEntries special linux file in Home dir
http://d.puremagic.com/issues/show_bug.cgi?id=8298 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev 2012-12-21 21:25:22 PST --- How to create such a special file, in order to reproduce the problem? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8291] dirEntry cannot handle root directories + unhandled exception causes crash
http://d.puremagic.com/issues/show_bug.cgi?id=8291
Vladimir Panteleev changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #1 from Vladimir Panteleev 2012-12-21
21:31:50 PST ---
(In reply to comment #0)
> 1) Wrong root handling api/params.
> To stat a root directory, the "GetFileAttributes" API must be used instead of
> "FindFirstFile".
> To stat all files in a root dir, "C:\*" must be passed to FindFirstFile.
> In all other cases, a path with [back]slash removed can be passed to
> "FindFirstFile".
> I know this in crazy, if you don't believe me, read CAREFULLY the
> FindFirstFile
> docs.
> P.S.:
> This should make you see that the dirEntries method may have some problems...
The following program works as expected, and prints the files/directories in
the root of my C: drive:
import std.stdio;
import std.file;
void main()
{
writeln(dirEntries(`C:\`, SpanMode.shallow));
}
Can you clarify the problem?
> 2) Crash
> The result of FindFirstFile is "enforced" in _init private method and NOT
> CAUGHT in the caller public method dirEntry, and this crashes the client app.
> It would be better to throw a FileException in _init and catch+rethrow it in
> dirEntry.
So what is the exact problem? Isn't a FileException thrown in either case?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8250] dirEntries fails to generate file list when compiled with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=8250
Vladimir Panteleev changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #4 from Vladimir Panteleev 2012-12-21
21:43:20 PST ---
Full test case:
---
import std.file;
void main()
{
mkdir("test8250");
scope(exit) rmdirRecurse("test8250");
write("test8250/a.txt", "test");
bool found;
auto dFiles = dirEntries("test8250/", "*.txt", SpanMode.shallow);
foreach (d; dFiles)
if (d.name == "test8250/a.txt")
found = true;
assert(found, "Can't find a.txt");
}
---
Succeeds with: dmd -run bug8250.d
Failswith: dmd -inline -run bug8250.d
Will attempt to reduce Phobos dependency and refile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
