[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889 --- Comment #8 from Kenji Hara 2011-06-30 00:14:51 PDT --- (In reply to comment #7) > But that's true of immutable as well. In reality, any struct literal which > exists at run time is stored in the executable as if it were immutable (just > as > for a string literal). ??? I'm not speaking about object const-ness. Yes, immutable struct literal will be stored in data-segment, but that is binary level issue, and definitely different from language semantics level. Give you an example. https://github.com/9rnsr/scrap/blob/master/typecons/unique.d This is my prototype code to improve std.typecons.Unique. In it, by receiving only rvalues for its initializing and assignment, Unique type can keep the uniqueness of stored object. Similar improvements will be able on Scoped!T. By receiving only rvalue for initializing, we can separate the struct object that allocated on stack and others not. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2391] Character array literals are not recognized as string literals
http://d.puremagic.com/issues/show_bug.cgi?id=2391 yebblies changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #2 from yebblies 2011-06-30 17:34:35 EST --- This has the same cause as bug 2391: array literals are not accepted when a compile-time string is required. *** This issue has been marked as a duplicate of issue 2156 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2156] A string initialized to [] in a template is not recognized as string
http://d.puremagic.com/issues/show_bug.cgi?id=2156 --- Comment #1 from yebblies 2011-06-30 17:34:35 EST --- *** Issue 2391 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6094] && doesn't shortcut properly with CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=6094 Don changed: What|Removed |Added Severity|regression |enhancement --- Comment #11 from Don 2011-06-30 00:42:19 PDT --- (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > I'm pretty sure this is a regression between DMD 2.052 and DMD 2.053. I > > > found > > > this 'regression' in template constraints: > > > > > > if( isPointer!T && isPointer!(pointerTarget!T) ) > > > > > > the problem is that if T is a string, then pointerTarget!T can not > > > compile. > > > This wouldn't be an issue if that meant the template constraint failed > > > gracefully, but instead it halts compilation. > > > > No, that's not a regression. && was never defined to work in that way. > > It's a Phobos bug which has been exposed. > > Don, this compiled prior to DMD 2.053 and was in my code, not Phobos. It _is_ > a > change from existing behavior. (Whether that change is a bug fix or a > regression is debatable) OK, I've figured this out. The change in behaviour was because of this commit: 3bba5ca9514121324769cd0f6d2537545481433d which suppresses spurious _error messages. What was happening with X && Y was that an error message was being generated while evaluating the Y, but because error messages were suppressed, you didn't see the error message. This is the important thing: it has ALWAYS generated an error message. Then, && gets constant folded. The constant folding assumes there are no errors, but because X is false, it const folds to false without looking at Y. (If it did look at Y, it would have crashed). This was incorrect behaviour, but normally it didn't matter, because an error message had been displayed already anyway. And finally, the template constraint didn't do a sanity check to see if any errors had occurred, it simply checked the result. The net effect of this was that (false && _error) normally didn't compile, but if it was inside a template constraint, it did compile! So it was definitely an accepts-invalid bug that got fixed. Not a regression. It wasn't supposed to do that, and there's nothing in the spec to suggest that it should have behaved in that way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #9 from Walter Bright 2011-06-30 00:43:08 PDT --- I appreciate what you're trying to do, but I tend to agree with Don. I'm not sure this is a correct thing to do. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4258] "auto ref" doesn't work in one or more cases
http://d.puremagic.com/issues/show_bug.cgi?id=4258 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright 2011-06-30 01:04:25 PDT --- (In reply to comment #2) > Patch create and send pull request: > https://github.com/D-Programming-Language/dmd/pull/51 With the patch, the error is the same as in Andrej's comment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2156] [] and null should be accepted where a compile-time string is required
http://d.puremagic.com/issues/show_bug.cgi?id=2156 yebblies changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|x86 |All Summary|A string initialized to [] |[] and null should be |in a template is not|accepted where a |recognized as string|compile-time string is ||required OS/Version|Windows |All --- Comment #2 from yebblies 2011-06-30 18:04:49 EST --- Fix for D2 https://github.com/D-Programming-Language/dmd/pull/180 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6226] Switch with impossible cases
http://d.puremagic.com/issues/show_bug.cgi?id=6226 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com --- Comment #1 from kenn...@gmail.com 2011-06-30 01:46:49 PDT --- V551 happens because in C a 'char' can be signed and people forget that. I doubt if the same argument could apply to D. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6229] %= and /= no longer work on char type
http://d.puremagic.com/issues/show_bug.cgi?id=6229 kenn...@gmail.com changed: What|Removed |Added CC||kenn...@gmail.com Platform|Other |x86 OS/Version|Windows |All --- Comment #1 from kenn...@gmail.com 2011-06-30 01:53:07 PDT --- The bug is introduced (or rather, exposed?) in commit 689ff. https://github.com/D-Programming-Language/dmd/commit/689ff -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6226] Switch with impossible cases
http://d.puremagic.com/issues/show_bug.cgi?id=6226
--- Comment #2 from bearophile_h...@eml.cc 2011-06-30 03:34:31 PDT ---
(In reply to comment #1)
> V551 happens because in C a 'char' can be signed and people forget that. I
> doubt if the same argument could apply to D.
Mistakes happen in D too, you use a variable with a range smaller than the
cases you have used in the switch. I'd like the compiler to tell me when a case
is impossible, because it's probably a bug, and this warning/error doesn't
damage generic code a lot because in generic code you are always able to add
cases using a "static if":
switch (foo) {
case 0: break;
static if (typeof(foo).max >= 200)
case 200: break;
default:
}
Regarding your specific comment, in my second example I have used a byte. In
another bug report (that's now a WONTFIX) I have argued that for the mind of
most programmers (me too) a byte is an unsigned value (this is also why in C#
you don't have just byte and ubyte, there is sbyte). If by mistake you think of
a D byte value as an unsigned value it's easy to add a case 200, that can't
happen.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4258] "auto ref" doesn't work in one or more cases
http://d.puremagic.com/issues/show_bug.cgi?id=4258 --- Comment #4 from Kenji Hara 2011-06-30 03:49:02 PDT --- (In reply to comment #3) Thanks for your merging. > (In reply to comment #2) > > Patch create and send pull request: > > https://github.com/D-Programming-Language/dmd/pull/51 > > With the patch, the error is the same as in Andrej's comment. Original test code is now invalid, because the template string argument of opOpAssign is just "+", not "+=". I just send pull request for adding test case. Please merge it. https://github.com/D-Programming-Language/dmd/pull/182 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889
--- Comment #10 from Kenji Hara 2011-06-30 04:37:33 PDT
---
OK. Here's another advantage of that.
struct S1{ int n; }
struct S2{ this(int n){} }
struct S3{ int n; void opAssign(S3 rhs){} }
void main()
{
S1(0) = S1(0); // Line 7
S2(0) = S2(0); // Line 8
S3(0) = S3(0); // Line 9
}
Line 7 and 8 are no effect codes. We can reject them by making struct literal
as rvalue.
Line 9 is an exception. S3.opAssign can have effect, so it is legal.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5889] Struct literal/construction should be rvalue
http://d.puremagic.com/issues/show_bug.cgi?id=5889
--- Comment #11 from Kenji Hara 2011-06-30 04:47:55 PDT
---
Another example.
In C++0x (gcc-4.5.1), following code prints "1".
It seems to me that the S() makes rvalue instead of lvalue.
#include
struct S {};
int f(S&&){ return 1; }
int f(const S&){ return 2; }
int main()
{
printf("%d\n", f(S()));
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #3 from Steven Schveighoffer 2011-06-30 07:24:09 PDT --- Like I said, I don't know what the right solution is. Previously I thought auto ref was the solution, but I'm not so sure. I agree operators need to accept rvalues, but I don't think const ref will be acceptable to Andrei. If this bug report was changed to "it should be possible to pass both rvalues and lvalues to operators," it would be a valid bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6221] Should be possible to pass struct function returns by 'const ref'.
http://d.puremagic.com/issues/show_bug.cgi?id=6221 --- Comment #4 from kenn...@gmail.com 2011-06-30 07:52:16 PDT --- Shouldn't opCmp be relaxed like opEquals in bug 3659? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 546] Error message for accessing a deprecated variable is doubled
http://d.puremagic.com/issues/show_bug.cgi?id=546 yebblies changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|x86 |All OS/Version|Windows |All --- Comment #3 from yebblies 2011-07-01 01:17:47 EST --- This patch fixes all the test cases in this report. https://github.com/D-Programming-Language/dmd/pull/183 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6230] New: Member functions can no longer be weakly pure
http://d.puremagic.com/issues/show_bug.cgi?id=6230
Summary: Member functions can no longer be weakly pure
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2011-06-30 08:39:36 PDT ---
(See http://lists.puremagic.com/pipermail/phobos/2011-June/005487.html and
comments in Phobos commit 4f28d** for existing discussion.)
After DMD commit 84b4f* a member function can no longer be pure, claiming
itself as a nested function. I believe this is a bug because the relevant DMD
code
Dsymbol *vparent = v->toParent2();
for (Dsymbol *s = sc->func; s; s = s->toParent2())
{
if (s == vparent)
break;
FuncDeclaration *ff = s->isFuncDeclaration();
if (!ff)
break;
if (ff->setImpure())
{ error("pure nested function '%s' cannot access mutable data
'%s'",
ff->toChars(), v->toChars());
break;
}
}
cannot check the case when 'vparent' is an aggregrate. Nevertheless, this leads
to commits d014a and 40def in druntime, and 4f28d in Phobos**, which probably
means this bug is INVALID.
Test case:
---
struct S {
int p;
int q() const pure {// <-- Error
return p;
}
}
class C {
int p;
int q() const pure {// <-- Error
return p;
}
}
int q2(ref const S s) pure {// <-- Currently OK
return s.p;
}
int q3(ref const C c) pure {// <-- Currently OK
return c.p;
}
---
y.d(4): Error: pure nested function 'q' cannot access mutable data 'p'
y.d(11): Error: pure nested function 'q' cannot access mutable data 'p'
---
* https://github.com/D-Programming-Language/dmd/commit/84b4f
** https://github.com/D-Programming-Language/druntime/commit/d014a
https://github.com/D-Programming-Language/druntime/commit/40def
https://github.com/D-Programming-Language/phobos/commit/4f28d
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6230] Member functions can no longer be weakly pure
http://d.puremagic.com/issues/show_bug.cgi?id=6230
--- Comment #1 from kenn...@gmail.com 2011-06-30 09:50:12 PDT ---
One possible patch:
diff --git a/src/expression.c b/src/expression.c
index 57cdd61..71f6239 100644
--- a/src/expression.c
+++ b/src/expression.c
@@ -1366,17 +1366,23 @@ void Expression::checkPurity(Scope *sc, VarDeclaration
*v, Expression *ethis)
* requiring each function in between to be impure.
*/
Dsymbol *vparent = v->toParent2();
-for (Dsymbol *s = sc->func; s; s = s->toParent2())
+Dsymbol *s = sc->func, *snext = s->toParent2();
+// Make sure we're really finding parent *functions*, not parent
+// class.
+if (vparent->isFuncDeclaration() || snext != vparent)
{
-if (s == vparent)
-break;
-FuncDeclaration *ff = s->isFuncDeclaration();
-if (!ff)
-break;
-if (ff->setImpure())
-{ error("pure nested function '%s' cannot access mutable
data '%s'",
-ff->toChars(), v->toChars());
-break;
+for (; s; s = s->toParent2())
+{
+if (s == vparent)
+break;
+FuncDeclaration *ff = s->isFuncDeclaration();
+if (!ff)
+break;
+if (ff->setImpure())
+{ error("pure nested function '%s' cannot access mutable
data '%s'",
+ff->toChars(), v->toChars());
+break;
+}
}
}
}
diff --git a/src/func.c b/src/func.c
index 9957d7f..1cccbed 100644
--- a/src/func.c
+++ b/src/func.c
@@ -2664,9 +2664,9 @@ enum PURE FuncDeclaration::isPure()
TypeFunction *tf = (TypeFunction *)type;
if (flags & FUNCFLAGpurityInprocess)
setImpure();
-enum PURE purity = tf->purity;
-if (purity == PUREfwdref)
+if (tf->purity == PUREfwdref)
tf->purityLevel();
+enum PURE purity = tf->purity;
if (purity > PUREweak && needThis())
{ // The attribute of the 'this' reference affects purity strength
if (type->mod & (MODimmutable | MODwild))
@@ -2676,6 +2676,9 @@ enum PURE FuncDeclaration::isPure()
else
purity = PUREweak;
}
+tf->purity = purity;
+// ^ This rely on the current situation that every FuncDeclaration has a
+// unique TypeFunction.
return purity;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1471] Linker error on template function. Error 42: Symbol Undefined ...
http://d.puremagic.com/issues/show_bug.cgi?id=1471
--- Comment #2 from kenn...@gmail.com 2011-06-30 10:25:34 PDT ---
Reduced test case for 1.068:
---
void main(){
const string s = "BOOM";
int gremlins = 0;
string bar = s[gremlins .. $];
}
---
Undefined symbols:
"_D1y4mainFZv8__dollark", referenced from:
_D1y4mainFZv8__dollark$non_lazy_ptr in y.o
(maybe you meant: _D1y4mainFZv8__dollark$non_lazy_ptr)
ld: symbol(s) not found
collect2: ld returned 1 exit status
--- errorlevel 1
---
The equivalent for 2.054:
---
void main(){
enum string s = "BOOM";
int gremlins = 0;
string bar = s[gremlins .. $];
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5062] Problem with a string slicing
http://d.puremagic.com/issues/show_bug.cgi?id=5062 kenn...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||kenn...@gmail.com Resolution||DUPLICATE --- Comment #1 from kenn...@gmail.com 2011-06-30 10:25:49 PDT --- *** This issue has been marked as a duplicate of issue 1471 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1471] Linker error on template function. Error 42: Symbol Undefined ...
http://d.puremagic.com/issues/show_bug.cgi?id=1471 kenn...@gmail.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from kenn...@gmail.com 2011-06-30 10:25:49 PDT --- *** Issue 5062 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6231] New: [patch] std.conv.to: Structs with toString and isInputRange match multiple templates.
http://d.puremagic.com/issues/show_bug.cgi?id=6231 Summary: [patch] std.conv.to: Structs with toString and isInputRange match multiple templates. Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Keywords: patch Severity: normal Priority: P3 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: sandf...@jhu.edu --- Comment #0 from Rob Jacques 2011-06-30 11:27:03 PDT --- If a struct defines a custom toString method and satisfies isInputRange, then to!string(Struct) will match multiple toImpl templates. The solution is to add an extra template constraint to the input range toImpl to detect structs with custom toString methods. [Line 194 in DMD 2.053] T toImpl(T, S)(S s, in T leftBracket = "[", in T separator = ", ", in T rightBracket = "]") if (isSomeString!T && !isSomeChar!(ElementType!S) && (isInputRange!S || isInputRange!(Unqual!S)) ) -This is the constraint to add. && !(is(S == struct) && is(typeof(&S.init.toString))) ) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5936] Regression(2.050): Segfault when forward-referencing pure auto-return member function with parameter.
http://d.puremagic.com/issues/show_bug.cgi?id=5936
--- Comment #3 from kenn...@gmail.com 2011-06-30 11:27:04 PDT ---
(In reply to comment #1)
> The segfault is a simple null pointer dereference which can easily be patched.
>
> mtype.c, TypeFunction::parameterEscapes, line 5369
>
> if (purity)
> { /* With pure functions, we need only be concerned if p escapes
> * via any return statement.
> */
> -Type* tret = nextOf()->toBasetype();
> -if (!isref && !tret->hasPointers())
> +Type* tret = nextOf() ? nextOf()->toBasetype() : NULL;
> +if (!isref && tret && !tret->hasPointers())
> { /* The result has no references, so p could not be escaping
> * that way.
> */
> return FALSE;
> }
This patch only fixes 5844. In git master this becomes
Internal error: toir.c 190
with or without your patch.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6231] [patch] std.conv.to/std.format.: Structs with toString and isInputRange match multiple templates.
http://d.puremagic.com/issues/show_bug.cgi?id=6231 Rob Jacques changed: What|Removed |Added Summary|[patch] std.conv.to:|[patch] |Structs with toString and |std.conv.to/std.format.: |isInputRange match multiple |Structs with toString and |templates. |isInputRange match multiple ||templates. --- Comment #1 from Rob Jacques 2011-06-30 12:04:07 PDT --- std.format.formatRange also suffers from a similar problem, although in this case it is one of choosing a non-character range over the custom toString routine. [Line 1171 in format.d in DMD 2.053] void formatValue(Writer, T, Char)(Writer w, T val, ref FormatSpec!Char f) if (isInputRange!T && !isSomeString!T The extra condition: && !(is(T == struct) && is(typeof(&T.init.toString))) ) And the toString exception needs to added to Line 1474 void formatValue(Writer, T, Char)(Writer w, T val, ref FormatSpec!Char f) if (is(T == struct) && (!isInputRange!T || is(typeof(&T.init.toString))) ) By the way, I like the idea of void toString(void delegate(const(char)[]) sink, FormatSpec fmt); void toString(void delegate(const(char)[]) sink, string fmt); but are which one is preferred? And if/when is Object going to switch over? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2521] Not possible to return immutable value by ref
http://d.puremagic.com/issues/show_bug.cgi?id=2521 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #7 from Walter Bright 2011-06-30 13:23:06 PDT --- https://github.com/D-Programming-Language/dmd/commit/099ed3c987c8cca5dbb8614e21b2a5de99a49252 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4718] Few Phobos modules renames
http://d.puremagic.com/issues/show_bug.cgi?id=4718 --- Comment #6 from bearophile_h...@eml.cc 2011-06-30 15:15:36 PDT --- KennyTM~: > But std.cover no longer exists in D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6232] New: And idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232
Summary: And idea for std.string.toStringz docs
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: websites
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-06-30 15:50:44 PDT ---
To the online docs of std.string.toStringz I suggest to add an example like
this, that shows how to use the D type system to avoid passing not
zero-terminated char* to C functions (C functions coming from C libraries,
etc):
import std.string: toStringz;
struct CcharPtr {
const char* ptr;
alias ptr this;
}
// example of C function
extern(C) size_t strlen(CcharPtr str);
CcharPtr toStringz2(string s) {
return CcharPtr(toStringz(s));
}
void main() {
string s1 = "this is ";
string s2 = s1 ~ "just a string";
auto cs = toStringz2(s2);
assert(s2.length == strlen(cs));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6232] And idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis 2011-06-30 17:27:01 PDT --- That's a lot to add to the documentation for something which is completely unnecessary to use or understand the function. And it would only make sense if it were considered best practice to do this, and I think that you're going to have a hard time convincing people that they should do this in the general case. The typical thing to do with toStringz is to just pass the result directly to a C function and be done with it. Your suggestion is completely overkill in such cases. This is an enhancement request, so I'm not going to just close it, but I really don't think that anything like this should be in the documentation. A function's documentation is for explaining what a function does and how its used, not for stuff like this. This sort of thing would only make sense if CcharPtr and tostringz2 were actually added to Phobos, in which case, the documentation would go on _them_, not toStringz. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6232] And idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232 --- Comment #2 from bearophile_h...@eml.cc 2011-06-30 18:18:46 PDT --- (In reply to comment #1) > That's a lot to add to the documentation for something which is completely > unnecessary to use or understand the function. Good documentation must show non-obvious but important usages of the functions too. See below. > And it would only make sense if > it were considered best practice to do this, and I think that you're going to > have a hard time convincing people that they should do this in the general > case. The typical thing to do with toStringz is to just pass the result > directly to a C function and be done with it. Your suggestion is completely > overkill in such cases. This suggestion of mine may be wrong, ad surely there are ways to improve it (in the name I've used too). But so far in D.learn I've seen three times people talk about bugs coming from not passing zero terminated strings to C functions. toStringz solves the problem, but you have to remember to use it in the first place. Languages with good type systems like Haskell, F#, ATS, etc show that tons of bugs are avoidable using type systems in a smarter way. D type system isn't as refined as Haskell or Scala one, but it's good enough, if used well, to avoid many C-string bugs. > This is an enhancement request, so I'm not going to just close it, but I > really > don't think that anything like this should be in the documentation. A > function's documentation is for explaining what a function does and how its > used, not for stuff like this. This example shows how to use D type system and toStringz. Tricks and smart usages are at the right place in docs. Delphi documentation shows this well. Another example are the itertools recipes present in the docs only: http://docs.python.org/library/itertools.html#recipes > This sort of thing would only make sense if > CcharPtr and tostringz2 were actually added to Phobos, in which case, the > documentation would go on _them_, not toStringz. This is probably not going to happen, Walter doesn't want "swallow" functions in Phobos. So they need to go in lists of "recipes" or examples in the docs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6232] An idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232 --- Comment #3 from Jonathan M Davis 2011-06-30 18:28:29 PDT --- Your suggestion doesn't help at all with remembering to use zero-terminated strings when calling C code. For that you have to remember that you need to do that and that toStringz is the function to use to get a zero-terminated string. Adding your example to toStringz's documenation wouldn't help anyone remember to use it. If anything is wrong with the type system, it's the fact that it implicitly converts arrays to pointers, but even if it required you to use the ptr property instead, people would still have to remember to use toStringz for strings. So, such a change to type system wouldn't help any. Are your suggestion only helps as far as the type system goes if all of the C functions in druntime or wherever use CcharPtr instead of char*, since if the function takes char*, you can still pass a string directly to them even if you have CcharPtr to use if you want to. So, I don't see how this suggestion helps much of anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6233] New: Compiler lists wrong module in an expression error
http://d.puremagic.com/issues/show_bug.cgi?id=6233
Summary: Compiler lists wrong module in an expression error
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2011-06-30
18:51:11 PDT ---
This happened in real code due to a mishap where I've accidentally removed the
name of a function in a function call.
.\test.d:
module test;
import bar.barmod;
void main()
{
(FALSE); // used to be Foo(FALSE);
}
void Foo(BOOL) { }
.\bar\barmod.d:
module bar.barmod;
alias int BOOL;
enum : BOOL {
FALSE = 0,
TRUE = 1
}
$ dmd test.d -I.
bar\barmod.d(5): Error: long has no effect in expression (0)
In my case it pointed the error to the WinAPI library, that was a real WTF
moment and it took me a while before I spotted where the syntax error really
was.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6232] An idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232 --- Comment #4 from bearophile_h...@eml.cc 2011-06-30 18:57:48 PDT --- (In reply to comment #3) > Your suggestion doesn't help at all with remembering to use zero-terminated > strings when calling C code. > Are your > suggestion only helps as far as the type system goes if all of the C functions > in druntime or wherever use CcharPtr instead of char*, since if the function > takes char*, you can still pass a string directly to them even if you have > CcharPtr to use if you want to. So, I don't see how this suggestion helps much > of anything. With extern(C) you are free to give to C functions a signature that you want. In this example strlen() is meant as an example of random user-defined function from some third-party C lib. Maybe using strlen() is not a clear enough example, I have to use the frobaz() C function instead. The idea here is that you define their signature using something like CcharPtr. If you do this, the type system will catch your bugs because you can't pass a char* to those C functions. Similar tricks, or ones based on more complex type system features, allow you to kill bugs in F# code, ATS code, etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6232] An idea for std.string.toStringz docs
http://d.puremagic.com/issues/show_bug.cgi?id=6232 --- Comment #5 from Jonathan M Davis 2011-06-30 19:30:18 PDT --- 1. It only helps if you're actually keeping zero-terminated strings around, which is likely an atypical use case. Usually, you pass it to the C function and forget about it. 2. Even if your suggestion does help prevent bugs, _none_ of the C functions in druntime are going to be declared to use CcharPtr, so it doesn't help at all unless you're declaring a bunch of C declarations yourself. So, it makes no sense to put the suggestion in the standard library's documentation. If CcharPtr were in druntime or Phobos that would be different, but it isn't. There are plenty of suggestions which could be given to improve code quality. That doesn't mean that they belong in the standard library's documentation. If there were some sort of page with tips for D programmers, then perhaps it could go there, but I really don't think that it has any business going in the standard docs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1553] foreach_reverse is allowed for delegates
http://d.puremagic.com/issues/show_bug.cgi?id=1553 yebblies changed: What|Removed |Added Keywords||accepts-invalid, patch Priority|P4 |P3 CC||yebbl...@gmail.com Platform|x86 |All Version|1.022 |D1 & D2 OS/Version|Windows |All Severity|enhancement |normal --- Comment #1 from yebblies 2011-07-01 14:44:15 EST --- https://github.com/D-Programming-Language/dmd/pull/184 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6229] %= and /= no longer work on char type
http://d.puremagic.com/issues/show_bug.cgi?id=6229 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2011-06-30 22:47:00 PDT --- https://github.com/D-Programming-Language/dmd/commit/136d88e45532d95434f4c3226a4078aca14da90a -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
