https://issues.dlang.org/show_bug.cgi?id=14035
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #16 from Nick Tr
https://issues.dlang.org/show_bug.cgi?id=14035
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=14035
Steven Schveighoffer changed:
What|Removed |Added
CC||timothee.co...@gmail.com
--- Comment
https://issues.dlang.org/show_bug.cgi?id=14035
hst...@quickfur.ath.cx changed:
What|Removed |Added
Keywords||accepts-invalid, CTFE
https://issues.dlang.org/show_bug.cgi?id=14035
Kenji Hara changed:
What|Removed |Added
Assignee|nob...@puremagic.com|k.hara...@gmail.com
Severity|minor
https://issues.dlang.org/show_bug.cgi?id=14035
yebblies changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=14035
Ketmar Dark changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #2 from Ke
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #3 from yebblies ---
(In reply to Ketmar Dark from comment #2)
> the same logic should allow this:
>
> string alice() (usize ln=__LINE__) {
> return "{ int t_"~ln~" = 42; }";
> }
> pragma(msg, alice!());
>
> yet somehow this is not wo
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #4 from Ketmar Dark ---
ln type is known in both cases. `usize` is `size_t`, if it matters. yet somehow
two `ln`s has *different* types. i can see how `(T ln=__LINE__)` can be
converted to char, as compiler is free to choose any integral
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #5 from Ketmar Dark ---
i.e. having such template that somehow deduces type for it's argument, despite
the explicitly written type, and doing that differently depending of the line
where template was instantiated is... very strange. it's
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #6 from yebblies ---
The type of ln doesn't change.
The template expands to something like
enum uint ln = 4;
enum alice = "{ int t_"~ln~" = 42; }";
As the compiler knows the _value_ for ln, it expands alice's initializer to
enum alice
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #7 from Ketmar Dark ---
the type IS changed. in no way compiler does runtime analysis to allow
converting `size_t` to `char`, it simply rejects such code. yet for
*explicitly* defined type in template compiler — for some unknown reason —
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #8 from yebblies ---
Feel free to make your own version of the compiler that works differently.
--
https://issues.dlang.org/show_bug.cgi?id=14035
Kenji Hara changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX
https://issues.dlang.org/show_bug.cgi?id=14035
Ketmar Dark changed:
What|Removed |Added
CC|ket...@ketmar.no-ip.org |
--
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #10 from Ketmar Dark ---
i did. yet i still can't see how this helps with three different `size_t` in D.
but i clearly see why D will never be popular, with it's roots in old-fashioned
"you have to know compiler internals to predict what
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #11 from Kenji Hara ---
(In reply to Kenji Hara from comment #9)
> and disallow conversions beyond the categories for non-polymorphic literals
> (eg. `4` type with uint).
Of course, even inside same category, loss of precision should als
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #12 from yebblies ---
(In reply to Kenji Hara from comment #9)
> (In reply to yebblies from comment #6)
> > Then, because it knows that 4 can fit in a char, it allows it to become
> > this:
> >
> > enum alice = "{ int t_"~cast(char)4~"
https://issues.dlang.org/show_bug.cgi?id=14035
Ketmar Dark changed:
What|Removed |Added
CC|ket...@ketmar.no-ip.org |
--
https://issues.dlang.org/show_bug.cgi?id=14035
Ketmar Dark changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #13 from K
https://issues.dlang.org/show_bug.cgi?id=14035
--- Comment #14 from Kenji Hara ---
(In reply to yebblies from comment #12)
> This is sort of the whole point of VRP
I think it's a problem in the current implemented semantics of VRP. Applying
VRP beyond the "type categories" will introduce human u
21 matches
Mail list logo
