[Issue 2638] New: auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 Summary: auto string var should be invariant(char)[], not char[] Product: D Version: unspecified Platform: PC URL: http://www.digitalmars.com/d/2.0/declaration.html#AutoDe claration OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: bugzi...@digitalmars.com ReportedBy: jlqu...@optonline.net auto s = string; // s is type char[6] Unless I'm misreading the spec, the type of s should be invariant(char)[6]. --
[Issue 2638] auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 --- Comment #1 from jarrett.billings...@gmail.com 2009-02-01 12:43 --- Uh, what compiler version are you using? If you're using a D1 compiler, then it should be char[6]. --
[Issue 2639] New: Hex and octal string values not completely specified
http://d.puremagic.com/issues/show_bug.cgi?id=2639 Summary: Hex and octal string values not completely specified Product: D Version: 2.023 Platform: PC URL: http://www.digitalmars.com/d/2.0/lex.html OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: bugzi...@digitalmars.com ReportedBy: jlqu...@optonline.net The spec implies that a string literal containing hex and octal values is assembled in UTF-8, but doesn't say so explicitly. The text says that hex and octal values can be used to build binary data. If you have something like: dstring ds = \U00101234\x7fd what are the actual bytes in the string ds? Without defining explicitly, it allows for 00 10 12 34 7f 00 00 00 on a big-endian machine as opposed to the probably intended 00 10 12 34 00 00 00 7f --
[Issue 2638] auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 --- Comment #2 from jlqu...@optonline.net 2009-02-01 13:04 --- (In reply to comment #1) Uh, what compiler version are you using? If you're using a D1 compiler, then it should be char[6]. Sorry, I'm referring to D2. Also, this is an issue with the spec web page, so the language version is in the URL and unambiguous :-) --
[Issue 2638] auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 --- Comment #4 from jlqu...@optonline.net 2009-02-01 14:16 --- (In reply to comment #3) Both the D1 and D2 specs are on Digital Mars' site, so no, it's not unambiguous. The URL includes 2.0 in the path. But I'll try to remember to set the version next time, sorry. --
[Issue 2640] New: Improve usability of the inner name trick
http://d.puremagic.com/issues/show_bug.cgi?id=2640
Summary: Improve usability of the inner name trick
Product: D
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: and...@metalanguage.com
The inner name trick consists of a template only defining a symbol of the
same name as itself. Then, any instantiation of the template will in fact shunt
to the defined inner symbol. Example:
template A(T) { alias T[] A; }
Using e.g. A!(int) will be entirely synonymous with int[].
This is a hugely useful feature that is bound to be heavily used in a variety
of templated code. Unfortunately, there is a limitation - the template is
disallowed from defining any symbol. The motivation of the limitation is that
the shunting mechanism would in fact disallow access to that member.
The fallout of this is that many nontrivial templates follow the pattern:
template Widget(T)
{
alias WidgetImpl!(T).Result Widget;
}
template WidgetImpl(T)
{
... actual implementation defining several private symbols ...
alias ...something... Result;
}
That way users have the convenience of using Widget!(T) instead of
Widget!(T).Result, and the implementor has the ability to define nontrivial
template code that defines and uses several symbols towards computing the
desired result. The obvious cost is that extra code must be written.
I'd like to find a solution to this because the pattern is starting to creep
really bad in Phobos. One idea is to allow a template using the inner name
trick to define any number of symbols inside. As long as those symbols are
accessed USING UNQUALIFIED ACCESS, they are looked up normally. That means that
inside the template itself, defining temporary aliases is fair game. As soon
as the template is closed, the user can't have access to the inner symbols.
Example:
template A(T)
{
alias T X; // define inner symbol X
alias X[] A; // use of UNQUALIFIED X ok
alias A!(int).X Y; // error: type int[] does not define X
}
So, in short: the template can define and use symbols at its leisure. Use of
the symbols follow the normal rule: first in the template's scope, then
outside. But if the template aliases itself using the inner name trick, then
the shunting is done prior to looking the name up (as is done today).
--
[Issue 2640] Improve usability of the inner name trick
http://d.puremagic.com/issues/show_bug.cgi?id=2640 --- Comment #1 from jarrett.billings...@gmail.com 2009-02-01 16:29 --- Agreed 100%. I think I even posted a suggestion to this effect years ago on the digitalmars.D board? I forget. --
[Issue 2638] auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 --- Comment #5 from 2kor...@gmail.com 2009-02-01 16:53 --- shall we close the issue? --
[Issue 2638] auto string var should be invariant(char)[], not char[]
http://d.puremagic.com/issues/show_bug.cgi?id=2638 --- Comment #6 from bra...@puremagic.com 2009-02-01 16:59 --- Why? string literals should be invariant in D2, so if that's not what's happening, then there's really a bug here. Is this report strictly a documentation bug or was there also code associated to demonstrate the problem? I'm assuming it's strictly a doc issue at the moment. --
[Issue 2640] Improve usability of the inner name trick
http://d.puremagic.com/issues/show_bug.cgi?id=2640
--- Comment #2 from 2kor...@gmail.com 2009-02-01 17:13 ---
Yeah, I have proposed that, too. I suggested marking all internal temporary
aliases as private for that purpose:
template WidgetImpl(T)
{
private alias ...something_complex... Tmp; // not visible from outside
alias ...something_else... WidgetImpl; // public
}
--
[Issue 2641] New: std.variant Variant's check for can append is wrong
http://d.puremagic.com/issues/show_bug.cgi?id=2641
Summary: std.variant Variant's check for can append is wrong
Product: D
Version: 2.023
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: bugzi...@digitalmars.com
ReportedBy: wbax...@gmail.com
The code below used in std.variant seems to be assuming that if a type can be
indexed, then it can also be appended to:
-
case OpID.catAssign:
auto me = cast(A*) pStore;
static if (is(typeof((*me)[0])) !is(typeof(me.keys)))
{
// array type; parm is the element to append
auto arg = cast(VariantN*) parm;
alias typeof((*me)[0]) E;
if (arg[0].convertsTo!(E))
{
// append one element to the array
(*me) ~= [ arg[0].get!(E) ];
}
else
{
// append a whole array to the array
(*me) ~= arg[0].get!(A);
}
---
This causes it to fail when trying to use a fixed-length struct, like a fixed
vec3 that provides an opIndex but no opCatAssign.
--
[Issue 2641] std.variant Variant's check for can append is wrong
http://d.puremagic.com/issues/show_bug.cgi?id=2641 and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED --
