[Issue 8233] New: std.array.array fails to compile with ranges of immutable elements which have a length property
http://d.puremagic.com/issues/show_bug.cgi?id=8233
Summary: std.array.array fails to compile with ranges of
immutable elements which have a length property
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-13 01:25:48
PDT ---
This fails to compile
import std.array;
void main()
{
dstring d = hello world;
auto e = array(d);
}
giving
/home/jmdavis/dmd2/linux/bin/../../src/phobos/std/array.d(55): Error: result[i]
isn't mutable
q.d(6): Error: template instance std.array.array!(immutable(dchar)[]) error
instantiating
If you use string rather than dstring, it works just fine. The line that fails
to compile in std.array.array is in the hasLength!Range portion, so clearly
it's an issue specifically with ranges which have a length property.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8229] string literals are not zero-terminated during CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=8229
--- Comment #3 from Don clugd...@yahoo.com.au 2012-06-13 01:44:42 PDT ---
(In reply to comment #2)
(In reply to comment #1)
This behaviour is intentional. Pointer operations are strictly checked in
CTFE.
It's the same as doing
int n = 0;
char c = [n];
which generates an array bounds error at runtime.
I think that would be stretching it too far. It is more like:
auto s = ['\0'];
auto q = s[0..0];
char c = *q.ptr;
That's an interesting interpretation. It can't be true for D1, where string
literals are fixed length arrays, but it could work for D2.
In D1 it's more like:
struct S
{
static char[3] s = ['a', 'b', 'c'];
static char terminator = '\0';
}
And every mention of it in the spec dates from D1.
Is the terminating null character still in the spec? A long time ago it was
in
there, but now I can only find two references to it in the current spec (in
'arrays' and in 'interfacing to C'), and they both relate to printf.
The most detailed is in 'interface to C', which states:
string literals, when they are not part of an initializer to a larger data
structure, have a '\0' character helpfully stored after the end of them.
which is pretty weird. These funky semantics would be difficult to
implement in
CTFE,
I guess this is from D1 times, when string literals were static arrays, and
doesn't apply anymore.
Could be. So the few parts of the spec that mention it are horribly
out-of-date.
Though it also applies to assigning to fixed length arrays.
immutable(char)[3] s = abc;
// Does this have a trailing zero?
and I doubt they are desirable. Here's an example:
const(char)[] foo(char[] s) { return abc ~ s; }
immutable bar = foo(xyz); // becomes a string literal when it leaves CTFE
Well, this is not specified afaics.
Hmm, maybe it isn't. The spec says almost nothing about the whole thing. What I
do know is that there is a lot of existing code that relies on this behaviour
(especially, abc ~ def having a trailing zero).
Pretty much the only thing the spec says is that you can use string literals
with printf.
Does TDPL mention it?
The spec definitely needs to be improved.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8233] std.array.array fails to compile with ranges of immutable elements which have a length property
http://d.puremagic.com/issues/show_bug.cgi?id=8233 --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-06-13 01:50:59 PDT --- https://github.com/D-Programming-Language/phobos/pull/630 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4364] ICE(class.c) compiling a struct def named 'Object' followed by a class definition
http://d.puremagic.com/issues/show_bug.cgi?id=4364 --- Comment #5 from Patrick Byrne pjlby...@gmail.com 2012-06-13 02:35:09 PDT --- Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7485] Incorrect BigInt Error Message
http://d.puremagic.com/issues/show_bug.cgi?id=7485 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||INVALID --- Comment #4 from Don clugd...@yahoo.com.au 2012-06-13 04:25:32 PDT --- I can't see any bug here. The error message is correct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7081] array slice assignment should check for opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=7081
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Component|Phobos |DMD
Summary|BigInt array slice int |array slice assignment
|assignment |should check for opAssign
--- Comment #1 from Don clugd...@yahoo.com.au 2012-06-13 05:03:17 PDT ---
This doesn't have anything to do with BigInt. Rather, it's a request for
implicit conversion to apply to array block assignment.
Reduced example:
struct S
{
void opAssign(int n) {}
}
void main()
{
S[20] s;
s[] = 6;
}
bug.d(9): Error: cannot implicitly convert expression (6) of type int to S[]
It seems reasonable enough. It could be problematic if the thing being assigned
is an array, eg
void opAssign(int[] n) {}
but we have that problem already with block assignment to arrays of dynamic
arrays.
AFAIK array block assignment isn't mentioned in the spec at all.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8234] New: symbols used in CTFE affect the function literal type
http://d.puremagic.com/issues/show_bug.cgi?id=8234
Summary: symbols used in CTFE affect the function literal type
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-06-13 07:33:14 PDT ---
DMD 2.059:
void foo(){
immutable int x = 0;
static assert(is(typeof(*(){enum e=x;return e;})==function)); // fail
}
The static assertion should pass.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8235] New: IsUserAnAdmin not in shell32.lib
http://d.puremagic.com/issues/show_bug.cgi?id=8235
Summary: IsUserAnAdmin not in shell32.lib
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Optlink
AssignedTo: nob...@puremagic.com
ReportedBy: stefan.sonnenb...@pythonmeister.com
--- Comment #0 from Stefan Sonnenberg stefan.sonnenb...@pythonmeister.com
2012-06-13 11:48:43 PDT ---
Given this code snippet:
8-
import std.c.stdio;
import std.c.windows.windows;
extern (Windows) BOOL IsUserAnAdmin();
int main(string[] args) {
return IsUserAnAdmin();
}
-8
and compiling it with
dmd test.d shell32.lib
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test.obj(test)
Error 42: Symbol Undefined _IsUserAnAdmin@0
--- errorlevel 1
IsUserAdmin is exported by shell32.dll and so this might be a bug ?
Bug reproducable on Windows Vista 32 Bit, DMD32 D Compiler v2.059
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8062] UFCS and operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=8062 --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com 2012-06-13 12:22:05 PDT --- (In reply to comment #2) (In reply to comment #1) As defined t shouldn't: UFCS presently only does go from fn(a,b, ...) - a.fn(b, ...); way. Well, no. UFCS transforms a.fn(b, ...) to fn(a,b, ...). My bad, I actually meant it a.fn --- fn(a,...) way. Which brings us to the point - request is Invalid then? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8062] UFCS and operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=8062 --- Comment #4 from timon.g...@gmx.ch 2012-06-13 12:37:21 PDT --- (In reply to comment #3) My bad, I actually meant it a.fn --- fn(a,...) way. Which brings us to the point - request is Invalid then? I don't think it is invalid. a + b - a.opBinary!+(b) - opBinary!+(a, b); Probably this is on the borderline between bug and enhancement request -- I think the documentation can be interpreted either way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8062] UFCS and operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=8062 --- Comment #5 from jens.k.muel...@gmx.de 2012-06-13 14:05:28 PDT --- (In reply to comment #4) (In reply to comment #3) My bad, I actually meant it a.fn --- fn(a,...) way. Which brings us to the point - request is Invalid then? I don't think it is invalid. a + b - a.opBinary!+(b) - opBinary!+(a, b); Probably this is on the borderline between bug and enhancement request -- I think the documentation can be interpreted either way. Which documentation are you referring to? I don't think this is an enhancement. How can it be an enhancement? Are there exceptions when UFCS has to be applied? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-06-13 14:55:42 PDT --- I have a patch for this specific case, but it's a kludge, not a general solution. The problem is that the context of the typeof(x) is not the context of where x was declared, hence it is unknown what scope qualifiers (such as Colour) need to be applied. Can you post an example of why you need this? Perhaps there's another way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #5 from Manu turkey...@gmail.com 2012-06-13 15:50:11 PDT ---
(In reply to comment #4)
Can you post an example of why you need this? Perhaps there's another way.
It's difficult for me to extract a concrete example (a very large context, in
work code), but essentially I'm creating functions/methods that match (wrap)
user declared function pointers, which include default args in the
declarations. The default args need to propagate to the magic wrappers.
There is no mechanism to copy a parameter list from one function type to
another (with names + default args), nor are there traits to get the argument
names, or the default arg expression, so I can only construct declarations for
mixins by parsing that string.
An alternative approach I can use (prefer) is to invert the problem, allowing
the user to define function prototypes (rather than function pointers), and
then procedurally produce the function body. Although this conflicts with the
limitation I posted in bug 8108, where you can't forward declare/prototype a
function in a module/class, and then define it later in the same scope.
The prototype would be declared by a user, and a later mixin would scan for
prototypes and produce the function bodies within the same module.
// user declares:
void Function(int x = 10); // note: default args are still important
// and using magic, mixin:
void Function(int x)
{
// generated body..
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-06-13 20:05:42 PDT --- Ok, I suggest abandoning this .stringof proposal as unworkable. Instead, how about a traits that gives the default arguments as an expression tuple? Also, the argument names shouldn't be necessary, you can just generate your own. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #7 from Walter Bright bugzi...@digitalmars.com 2012-06-13
20:50:27 PDT ---
Suppose I made this work:
-
template ParameterTypeTuple(alias foo)
{
static if (is(typeof(foo) P == function))
alias P ParameterTypeTuple;
else
static assert(0, argument has no parameters);
}
int func(int i, long j = 7) { return 3; }
alias ParameterTypeTuple!func PT;
int bar(PT) { return 4; }
pragma(msg, typeof(bar));
void main()
{
bar(1);
}
I.e. the default argument is propagated to the tuple. Will that work for you?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8233] std.array.array fails to compile with ranges of immutable elements which have a length property
http://d.puremagic.com/issues/show_bug.cgi?id=8233 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-13 21:16:55 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5c3d2199316ab24c0cb3cffbacb83d41190459e7 Fix for issue# 8233. std.array.array fails to compile with ranges of immutable elements which have a length property https://github.com/D-Programming-Language/phobos/commit/c05e6e4ccea6b4a3a2097abc9d4b5c82e0213c91 Merge pull request #630 from jmdavis/8233 Fix for issue# 8233. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8233] std.array.array fails to compile with ranges of immutable elements which have a length property
http://d.puremagic.com/issues/show_bug.cgi?id=8233 --- Comment #3 from github-bugzi...@puremagic.com 2012-06-13 21:20:10 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/63732aed0b968c4639d3304db545ec420e7b97bb Updated changelog for fix to issue# 8233. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #8 from Walter Bright bugzi...@digitalmars.com 2012-06-13
22:23:21 PDT ---
Note that the default argument can be retrieved using something like:
PT[1] getDefault(PT a) { return a[1]; }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3150] cast from dynamic array to ulong is allowed
http://d.puremagic.com/issues/show_bug.cgi?id=3150 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-06-13 22:27:45 PDT --- Won't fix for D1, as that would change existing behavior. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3150] cast from dynamic array to ulong is allowed
http://d.puremagic.com/issues/show_bug.cgi?id=3150 --- Comment #8 from github-bugzi...@puremagic.com 2012-06-13 22:26:50 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b0a0e35d23c996d6e068e2b859f2f51506f535f0 Issue 3150 - cast from dynamic array to ulong is allowed This patch makes this deprecated behavior. https://github.com/D-Programming-Language/dmd/commit/cc79fc96dc05742e07d03e4c575307f47f1d46dc Merge pull request #661 from yebblies/issue3150 Issue 3150 - cast from dynamic array to ulong is allowed -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
--- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-06-13
22:35:21 PDT ---
Or better:
PT[1] getDefault(PT[1..2] a) { return a[0]; }
An example:
-
import std.stdio;
template ParameterTypeTuple(alias foo)
{
static if (is(typeof(foo) P == function))
alias P ParameterTypeTuple;
else
static assert(0, argument has no parameters);
}
int func(int i, long j = 7) { return 3; }
alias ParameterTypeTuple!func PT;
int bar(PT) { return 4; }
pragma(msg, typeof(bar));
pragma(msg, PT[1]);
PT[1] boo(PT[1..2] a) { return a[0]; }
void main()
{
writeln(boo());
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #10 from Walter Bright bugzi...@digitalmars.com 2012-06-13 22:35:54 PDT --- I think that's a better solution, so I'm marking this as won't fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8221] typeof(null) rejected as return type for covariant overrides
http://d.puremagic.com/issues/show_bug.cgi?id=8221 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-06-13 22:50:28 PDT --- Why should this compile? What is the compelling reason? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8221] typeof(null) rejected as return type for covariant overrides
http://d.puremagic.com/issues/show_bug.cgi?id=8221 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8220] invalid function call not detected during semantic analysis
http://d.puremagic.com/issues/show_bug.cgi?id=8220 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-13 22:59:19 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f20292b8738155431589915166770abd8a2ce82a fix Issue 8220 - invalid function call not detected during semantic analysis https://github.com/D-Programming-Language/dmd/commit/cb3da3bf9e3f54ec3e89061c99adfd54045fbd80 Merge pull request #1000 from 9rnsr/fix8220 Issue 8220 - invalid function call not detected during semantic analysis -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
