Andrei, your explanation is almost the same as was my understanding. Thank you.
My shallow thought:
const T makes automatically reference. It is convenient.
Right thinking:
D has no semantics dividing copying/referencing, against has
dividing rvalue/lvalue.
D should support this like T(copyi
Hello, all.
I tried to ModuleOf!T in some day. It may works like this:
module mod.a;
struct S{}
struct Nest{
struct S{}
}
module test;
import mod.a;
static assert(ModuleOf!(S) == "mod.a");
static assert(ModuleOf!(Nest.S) == "mod.a");
Partially I succeed to get module name of mod.a.S b
2010/12/15 Simen kjaeraas :
> kenji hara wrote:
>
>> I think that D should support __traits(isModuleName, ModuleName).
>>
>> Do you think?
>
> A way to traverse the hierarchy of identifiers would be nice.
> There is currently no way to identify an identifier as a
I tested this issue.
I think mangledName does not support nested function.
I'll try to resolve it.
Kenji Hara
2010/12/23 Andrej Mitrovic :
> import std.stdio;
> import std.demangle;
> import std.traits;
>
> void main()
> {
> void test()
> {
> }
>
Sorry, current dmd does't provide the mangled name from function symbol.
see http://d.puremagic.com/issues/show_bug.cgi?id=2774
2010/12/24 kenji hara :
> I tested this issue.
> I think mangledName does not support nested function.
> I'll try to resolve it.
>
> Kenji H
Today, I also encountered this bug. Non-static function should be
preferred to static function over the instance.
Kenji
2010/11/29 bearophile :
> Dmitry Olshansky:
>
>> What's the problem?
>
> As far as I know opCall is currently broken. See:
> http://d.puremagic.com/issues/show_bug.cgi?id=4053
>
fault arg
will be ignored (in my opinion), is this expected?
// returning function pointer/delegate type can have default args?
int delegate(int n = 10) foo(int x) { ... }
If we can take agreements each other about them, it may be supported.
Kenji Hara
2012/8/27 Walter Bright :
> On 8
OK. I have finished working to implement it as a new pull request.
https://github.com/D-Programming-Language/dmd/pull/1102
It contains several test suites that indicate which case is supported or not.
https://github.com/D-Programming-Language/dmd/pull/1102/files#L6R1
Regards.
Kenji Hara
2012/8
I have commented to the pull.
I don't like adding convenient interfaces to std.format module.
https://github.com/D-Programming-Language/phobos/pull/777#issuecomment-8385551
Kenji Hara
2012/9/8 monarch_dodra :
> On Friday, 7 September 2012 at 15:34:12 UTC, monarch_dodra wrote:
>>
&
;
int n = formattedRead(dummy, fmt, args...);
assert(dummy.empty); // You can assert that remains should be empty.
formattedRead returns multiple states (the values which are read, how
many values are read, and remains of input), so allowing to ignore
them would introduce bad usage and possibilities of bugs.
Kenji Hara
));
static assert(is(typeof(dup(parr)) == int*[]));
immutable S[] isarr = dup(sarr);// allowed!
immutable int[] inarr = dup(narr); // allowed!
And today, dup function is used with UFCS.
int[] marr;
immutable int[] iarr = marr.dup();
Finally, built-in dup and idup are merged
Thanks for quick response.
2012/9/10 nazriel :
> Does anybody told you already that you freaking amazing?!
> This rox, I've already seen it on GH.
>
> Kenji for president++!
>
2012/9/10 Adam D. Ruppe :
> On Sunday, 9 September 2012 at 15:32:01 UTC, kenji hara wrote:
>>
>> Then returned value can be implicitly convertible to immutable(E[]).
>
>
> What about rebindable with auto? For example:
>
> void main() {
> char[] a = "
Yes, This works just as expected.
import std.stdio;
void main()
{
char[] a = dup("Hello");
string b = dup(a);
writeln(a); // prints "Hello"
writeln(b); // prints "Hello"
assert(cast(void*)a.ptr !is cast(void*)b.ptr); // elements are duplicated
Instead of :
immutable iarr = marr.dup(); // In the future, () would not be necessary
Is really handy? Yes, it is 6(or 4) characters shorter. But I can't
see it *handy*.
"idup" is still odd name to me.
Kenji Hara
2012/9/10 Timon Gehr :
> On 09/09/2012 05:44 PM, kenji hara wrote:
&
2012/9/10 Timon Gehr :
> On 09/09/2012 07:06 PM, kenji hara wrote:
>>
>> An advantage of generic dup() is to allow copying of const arrays.
>>
>> void main()
>> {
>> class C {}
>> const C[] ca = new C[3];
>> //ca.dup;
>>
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
Kenji Hara
// Then, now the code is broken implicitly!
}
This is a hijacking of local scope, and it is awful.
P.S.
It seems to me the root problem is that using a raw-identifier for the
start of the inference.
If there is a symbol literal, the problem may be solved.
test('bar); // bar is a symbol, so it does not refer any normal declarations
Kenji Hara
','r'] ~ null; // ['s','t','r']
4) After semantics _and_ optimization, polysemous string literal which
represented as like
4-1) "str" is typed as immutable([wd]?char)[] (The char type is
depends on the literal suffix).
4-2) ['s','t','r'] is typed as ([wd]?char)[] (The char type is
depends on the common type of its elements).
5) In object file generating phase, string literal which typed as
5-1) immutable([wd]?)char[] is stored in the executable and
implicitly terminated with \0.
5-2) [wd]?char[] are stored in the executable as the original image
and implicitly 'dup'ed in runtime.
Additionally, in following case, both concatenation should generate
polysemous string literals in CT and RT.
Because, after concatenation of chars and char arrays, newly allocated
strings are *purely immutable* value and implicitly convertible to
mutable.
immutable char ic = 'a';
pragma(msg, typeof(['s', 't', ic, 'r'])); // prints const(char)[]
immutable(char)[] s = ['s', 't', ic, 'r']; // BUT, should be allowed
char mc = 'a';
pragma(msg, typeof("st"~mc~"r")); // prints const(char)[]
char[] s = "st"~mc~"r"; // BUT, should be allowed
Kenji Hara
= void", but you may also run into problems:
> c)1) If T is immutable, that's illegal.
> c)2) The compiler may complain if you use t, due to access to uninitialized.
IMO, this is just a compiler bug. If a variable has VoidInitializer,
it should always become a runtime value.
Kenji Hara
(== the value itself is never undefined), but not
constructed (might be logically invalid object).
2) If T is nested struct, it's frame pointer is always null. It might
cause access violation by its member function call.
I came up with just now: The use of such unsafe T.init should be
allowed only inside @system/@trusted functions.
I think it is acceptable limitation.
Thoughts?
Kenji Hara
that's supposed to disable the init property), and it doesn't actually work.
My argue is simple: If your argument is proper behavior, you never
move NonNull object.
Kenji Hara
2012/10/6 Jonathan M Davis :
> On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>> 2012/10/6 Jonathan M Davis :
>> > Regardless, we need to better sort out how disabling init works. It was my
>> > understanding that the correct way to do it was to
>
> Yep.
>
> Paging Dr. Kenji!
The result of my challenging.
https://github.com/D-Programming-Language/dmd/pull/1187
Kenji Hara
[OT] deprecated attribute is yet not correctly implemented by the compiler.
http://d.puremagic.com/issues/show_bug.cgi?id=7619
Kenji Hara
2012/11/7 Walter Bright :
> I know there's been some long term unhappiness about the deprecated
> attribute - it's all-or-nothing approac
Now I'm working that.
Kenji Hara
2012/11/16 Don Clugston
> On 16/11/12 05:15, Rob T wrote:
>
>> On Friday, 16 November 2012 at 03:41:45 UTC, Stugol wrote:
>>
>>> Event_t e2;// Will compile!
>>>>
>>>
>>> Yeah but tha
Done.
https://github.com/D-Programming-Language/dmd/pull/1295
Kenji Hara
2012/11/16 kenji hara
> Now I'm working that.
>
> Kenji Hara
>
> 2012/11/16 Don Clugston
>
>> One of the oldest open enhancement requests is on this topic:
>>
>> http://d.puremag
d=9062
It will distinguish &propfunc and &(propfunc), the former returns a
function poiinter of propfunc, and the latter returns an address of
propfunc result.
The real example about that is here.
https://github.com/D-Programming-Language/phobos/pull/968/files#L0L1136
How about that?
Kenji Hara
Note that, std.typecons.Proxy implements such template member function
forwarding by opDispatch nesting.
If curious, you can look its implementation.
Kenji Hara
2012/12/7 deadalnix
> On Thursday, 6 December 2012 at 21:49:21 UTC, Phil Lavoie wrote:
>
>> I mean automatically dispatch
Because detecting that requires code flow analysis.
Note that it is completely different from CTFE.
Kenji Hara
2012/12/13 Pacoup
> On Thursday, 13 December 2012 at 04:26:52 UTC, Mehrdad wrote:
>
>>
>> It's C++ philosophy imposed on the C#-like aspects of the langua
D does not support such implicit *construction* in return statement and
function argument.
It is a current language design, and not a bug.
Kenji Hara
2012/12/13 Simen Kjaeraas
> On 2012-22-13 04:12, Jonathan M Davis wrote:
>
> On Wednesday, December 12, 2012 13:35:59 Walter Bri
removing @[] syntax. X months after? In version 2.0yy?
You should say much better answer than *in the future*.
Kenji Hara
2012/12/14 Walter Bright
> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>
>> 1. How much work would it be for the guys at Remedy Games to convert their
>> c
I think we should have -future/-f switch and @future attribute.
It is a rough idea, but seems a required compiler feature.
Kenji Hara
2012/12/14 Walter Bright
> On 12/13/2012 5:33 PM, kenji hara wrote:
>
>> Yet not released feature is not visible for almost D users.
>> What y
I have recently added a note about "init property is sometimes unsafe".
https://github.com/D-Programming-Language/d-programming-language.org/pull/201
To reduce the risk, I have proposed an enhancement for .init property usage.
http://d.puremagic.com/issues/show_bug.cgi?id=8752
would cause an overflow.
Calling func2(result); is accidentally works IMO.
The root cause is saving _items.front in joiner.Result.ctor, and using it
later.
If you calculate joiner.Result.front every time, problem will disappear.
@property auto ref front()
{
//return _current.front;
return _items.front.front;
}
Kenji Hara
http://d.puremagic.com/issues/show_bug.cgi?id=6207#c1
https://github.com/D-Programming-Language/dmd/pull/459
Kenji Hara
t; {
>>> string s;
>>> float f;
>>> }
>>>
>>> auto c = to!C(S("5", 2.5f));
>>> assert(c.i == 5 && c.s == "2.5");
>>>
>>
>> So C's s field maps to S's f field, not it's s field? That seems
>> unintuitive and bug prone.
I'm agree with bearophile.
> This isn't name to name mapping but field to field mapping.
I think std.conv.to should provide the *safe natural conversion*.
Field-to-field conversion seems not natural, and it is called
'Structural conversion'.
Kenji Hara
u are considered distinct types,
>> although the template parameter must in both cases be of type uint
>> and have value 1 and thus be identical.
>>
>> What's going on here?
>
> It's a bit similar to bug 1641.
Bug 1641 is already fixed. That issue does not occur with newest dmd.
And, it is bug 3467. I have already posted dmd patch.
http://d.puremagic.com/issues/show_bug.cgi?id=3467
https://github.com/D-Programming-Language/dmd/pull/449
Kenji Hara
This is typeof(super) problem.
When typeof(this) has some qualifiers (e.g. const, immutable, shared,
...), typeof(super) should have same qualifiers.
I filed this issue into bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=6848
Kenji Hara
2011/10/25 Andrew Wiley :
> My understanding
+1
I think 5899 is related issue.
Kenji Hara
2011/10/26 Gor Gyolchanyan :
> I agree. Null is a very common special-case value and overloading may
> be necessary based on that special-case value. Currently doing so
> means accepting any kind of typeless pointer (which is certainly not
&g
https://github.com/D-Programming-Language/dmd/pull/476
The pull request implementing that enhancement.
Kenji Hara
2011/10/27 kenji hara :
> +1
> I think 5899 is related issue.
>
> Kenji Hara
>
> 2011/10/26 Gor Gyolchanyan :
>> I agree. Null is a very common special-case v
--1;
It you want to reduce duplication of long code, you can use string mixin.
enum code = q{ ...long code... };
static if (is(typeof({ mixin(code); })))
{
mixin(code);
}
else
{
...
}
Kenji Hara
2011/10/31 Mehrdad :
> I've written this piece of code a fair number of times:
>
>
ple of local variable symbols", it is similar
to follows.
auto __list0 = TestEnum.ONE;
auto __list1 = TestEnum.TWO;
auto __list2 = TestEnum.THREE;
auto __list3 = TestEnum.FOUR;
alias TypeTuple!(list0, list1, list2, list3) list;
list itself is compile time tuple, but its elements are evaluated at
runtime. Loop C is unrolled like A and B, but the conditions are
evaluated at runtime, then compiler does not warn the branches as
unreachable.
Kenji Hara
2011/11/3 Don :
> Maybe we should suppress unreachable code warnings inside unrolled code.
I don't agree with this opinion of you.
It is useful when we write generic code.
Kenji Hara
performance).
I don't know why you want to reduce warnings that (probably) you expects.
Kenji Hara
2011/11/4 Nick Sabalausky :
> "kenji hara" wrote in message
> news:mailman.655.1320322897.24802.digitalmar...@puremagic.com...
>> 2011/11/3 Nick Sabalausky :
>>> I don't know much about the internals of DMD, but would this make any
>>> sense?:
>>
s.aa[key]) are part of 'this'. Therefore line 8 and 9 cannot bypass
const type checking, even if inside constructor, then should be
rejected.
I have call this concept "transitively modifiable", and I have
implemented it with dmd/pull/166.
"Transitively modifiable" is only checked inside constructor, and
allow more flexible initializing.
I think this is reasonable improvement.
Kenji Hara.
in()
{
S s;
S* ps = [makecopy(s)].ptr;
// print "postblit"
}
If you use it, please be careful.
Kenji Hara.
2011/11/13 Timon Gehr :
> On 11/12/2011 03:39 PM, deadalnix wrote:
>>
>> Hi all,
>>
>> We recently had a discution on #D about copying a struct on the
It has been already filed in bugzilla?
If so, I'd like to fix it.
Kenji Hara
2011/11/13 Andrei Alexandrescu :
> On 11/12/11 8:39 AM, deadalnix wrote:
>>
>> Hi all,
>>
>> We recently had a discution on #D about copying a struct on the heap and
>> getting a po
Maybe it increases from 2.055.
Now std.uni module has big tables for dealing with Unicode code points
correctly.
And, the pair of 2.057 and new std.regex module has same issue.
Kenji Hara
2011/12/11 Trass3r :
>> import std.stdio;
>> int main(){
>> writefln("Hello
Treating whole constant arrays as ranges by automatically shedding the
top-level const is good.
But realizing it by language semantic change is definitely bad.It
breaks IFTI rule, and adding special case will make difficult to learn
language.
Instead of language change, we can add specializations
2011/12/11 bearophile :
> kenji hara:
>
>> It breaks IFTI rule,
>
> What do you mean?
I mean following code comment will not become true.
void func(T)(T prm){}
void main(){
X arg;
func(arg); // T is deduced to typeof(arg)
}
>
>
>> and adding special cas
2011/12/11 Andrei Alexandrescu :
> On 12/10/11 4:31 PM, kenji hara wrote:
>>
>> Treating whole constant arrays as ranges by automatically shedding the
>> top-level const is good.
>> But realizing it by language semantic change is definitely bad.It
>> breaks IFTI r
edent convinced me.
Thanks.
Kenji Hara
2011/12/11 kenji hara :
> 2011/12/11 Andrei Alexandrescu :
>> On 12/10/11 4:31 PM, kenji hara wrote:
>>>
>>> Treating whole constant arrays as ranges by automatically shedding the
>>> top-level const is good.
>>&g
xample, this code can compile without error.
static assert(is(typeof(doNothing) == function));
doNothing is non-property free function, so its type is function type.
I agree that is(X == function) is bit difficult to understand, but it
is consistent feature and there is no bug.
Kenji Hara
2011/12/11 Timon Gehr :
> On 12/11/2011 12:35 AM, kenji hara wrote:
>>
>> 2011/12/11 deadalnix:
>>>
>>> Hi,
>>>
>>> I was working with std.concurrency and discovered a (now reported) bug
>>> about
>>> receive and function. It l
Posted a test patch to realize the suggestion.
https://github.com/D-Programming-Language/dmd/pull/554
Kenji Hara
2011/12/11 kenji hara :
> OK. I agree to the suggestion.
>
> I've been afraid that increasing IFTI rule is making the language
> learning difficult.
> It comes
.
Kenji Hara
2011/12/11 Andrew Wiley :
> ---
> class Bob {
> }
>
> void doSomething(T)(Bob bob, T data) {
> }
>
> void main() {
> doSomething(null, 5); // Error: template test.doSomething(T) does not
> match any function template declaration
> // Error: te
; type in D).
>
> If this ends up being viable, this is actually easier to explain than the
> current rules for inout. We just have to make sure the rules are sound
> before doing something like this.
>
> -Steve
Against an inout function that does not return inout type:
- the number of inout parameters should be 2 more?
- at least one parameter should have 'out' or 'ref' storage class as a
*return parameter*?
But I'm not sure these restrictions are necessarily required.
Kenji Hara
2011/12/13 Timon Gehr :
> On 12/13/2011 09:41 AM, kenji hara wrote:
[snip]
>>
>> Against an inout function that does not return inout type:
>> - the number of inout parameters should be 2 more?
>
> If we required that, then IFTI would also have to replace inout with co
Please file it into bugzilla, because it is a bug.
I'll post a patch to fix it.
Kenji Hara
2011/12/22 Andrew Wiley :
> Is this a bug, or are templated struct constructors not allowed to
> call other constructors?
>
> ---
> struct A {
> this(T)(T thing, int i) {
>
ProxyOf rewrites the expression
> obj.foo!(bar, baz)(a, b);
to
obj.opDispatch!("foo").opDispatch!(bar, baz)(a, b)
// opDispatch!("foo").opDispatch generates a temporary member template
for forwarding.
// And it is actually processed as 'eponymous template'.
The patch
https://github.com/D-Programming-Language/dmd/pull/558
implements the two phases of inout resolution.
Until merging of it, I'll not post a patch to relax inout rule.
Kenji Hara
2011/12/13 Steven Schveighoffer :
> Currently, the rules of inout say you cannot put inout on a p
#x27;m naming it 'ProxyOf', and it supports various of forwardings,
function call, property access, and specialized template member
function.
Kenji Hara
2011/12/27 Andrei Alexandrescu :
> On 12/26/11 7:25 PM, Peter Alexander wrote:
>>
>> Following up to this, how do I acce
I've posted a patch to fix the bug.
https://github.com/D-Programming-Language/dmd/pull/587
Please wait until be merged it.
(But I don't know when it will be done.)
Kenji Hara
2011/12/28 Caligo :
>
>
> On Tue, Dec 27, 2011 at 9:10 AM, Adam D. Ruppe
> wrote:
>>
>&g
ge features to deal with it.
>
>
>> We need .raw and we must abolish .length and [] for narrow strings.
>
>
> I don't believe that fixes anything and breaks every D project out there.
> We're chasing phantoms here, and I worry a lot about over-engineering
> trivia.
>
> And, we already have a type to deal with it: dstring
I fully agree with Walter. No need more wrapper for string.
Kenji Hara
A happy new year!
from Japan
Kenji Hara
2012/1/1 Andrei Alexandrescu :
> to the entire D community!
>
> Andrei
functionIssue 6083 - [tdpl] There can be only one
alias this.Issue 7132 - [tdpl] Exponential operator ^^ for integrals
does not compile without any import ...
Kenji Hara
2011/12/23 Andrei Alexandrescu :
> I've recently finished marking all sample code in TDPL that won't currentl
n presence of variadic function
Issue 6083 - [tdpl] There can be only one alias this.
Issue 7132 - [tdpl] Exponential operator ^^ for integrals does not
compile without any import
...
Kenji Hara
2011/12/23 Andrei Alexandrescu :
> I've recently finished marking all sample code in TDP
The definition of postblit generates an non-templated built-in
opAssign implicitly.
And it conflicts with your templated opAssign.
It is already filed in bugzilla.
Issue 4424 - Copy constructor and templated opAssign cannot coexist
http://d.puremagic.com/issues/show_bug.cgi?id=4424
Kenji Hara
code might be rejected correctly.
So relaxing inout rule is more reasonable now.
Kenji Hara
tically.
foreach (i, e; zip(sequence!"n", range))
{
// i = 0, 1, 2, ...
// e = elements of range
}
So extra unpacking syntax is not need.
Kenji Hara
gt; void main() {
> auto ap = [P(1,2), P(3,4), P(5,6)];
> foreach ((x, y); ap) // <== std.typecons.tuple unpacking
> writeln(x, " ", y);
> }
Therefore, follows would work.
auto ap = [P(1,2), P(3,4), P(5,6)];
foreach (x, y; ap) //
writeln(x, " ", y);
Kenji Hara
Precise documentation is not yet written. The original issue is
http://d.puremagic.com/issues/show_bug.cgi?id=6366
Kenji Hara
2012/1/24 Andrei Alexandrescu :
> On 1/23/12 6:40 PM, kenji hara wrote:
>>
>> Today, foreach can expand the front tuple automatically.
>>
>>
istency.
Kenji Hara
2012/1/24 bearophile :
> kenji hara:
>
>> std.range.zip makes a range of std.typecons.Tuple, not
>> std.typetuple.TypeTuple.
>> Then foreach statement supports the std.typecons.Tuple unpacking of
>> range.front.
>
> Ah, right.
>
>
>
What version do you use?
In 2.058head(commit f8887855), `dmd -H -c test.d` succeeds to compile
without DMD assertion.
Kenji Hara
2012/1/23 Adam Wilson :
> Does anyone have any idea why DMD would assert with the following assert on
> this code while building the druntime during DI gene
I think this is a current implementation problem.
In this case, just `override void foo()` in class D should override
the method in C.
And `void foo()const` should be a new overlodad of foo.
Kenji Hara
2012/2/17 Timon Gehr :
> On 02/17/2012 02:33 PM, Timon Gehr wrote:
>>
>>
>&
be fixed with deprecating, -d
option allows this annoying overriding.
// It is worse than 2.058 and before.
}
Kenji Hara
2012/2/17 kenji hara :
> I think this is a current implementation problem.
>
> In this case, just `override void foo()` in class D should override
> the m
After some thoughts, I agree that inheritance of pure @safe, and
nothrow is good feature.
But I disagree to const inference, because const attribute interacts
with overloadings.
Kenji Hara
2012/2/17 Walter Bright :
> Given:
>
> class A { void foo() { } }
> class B : A { overri
t(int)) dg) {
dg(x);
}
void main() {
int a;
foo(a, (ref int x){ x = 10; }); // don't break foo's inout-ness,
so should be allowed
assert(a == 10);
}
How about?
Kenji Hara
2012/2/19 Stewart Gordon :
> At the moment, if a function has an inout parameter, it must have
Hisayuki Mima's ctpg is compile-time parser generater, and the
generated parser works in compile time!
https://github.com/youkei/ctpg
Kenji Hara
2012/2/26 d coder :
>> How different is what you want to do from CTFE?
>> http://dlang.org/function.html
>
>
> I do not want
gt;
> I just checked out tag v2.054 of dmd from git, and the same error
> happens. I guess it's a bug that nobody ran into before?
It is a bug yet not fixed.
http://d.puremagic.com/issues/show_bug.cgi?id=6174
Kenji Hara
2012年4月10日11:22 Andrei Alexandrescu :
> On 4/9/12 9:03 PM, kenji hara wrote:
>> It is a bug yet not fixed.
>> http://d.puremagic.com/issues/show_bug.cgi?id=6174
>
> I'll note that fixing this bug is more difficult than it might seem,
> particularly when immutable membe
It conflicts with ”alias this” syntax.
template Inherits(T)
{
T value;
alias T Inherits; // (1) Inherits!int == int
alias T this; // (2) declares "alias this"!
}
struct S {
mixin Inherits!int; // (1) invalid or (2) mixing alias this declaration?
}
Kenji Hara
2012年4月12日
No. Current implementation doesn't enforce it.
Kenji Hara
2012年4月12日18:21 Daniel Murphy :
> "kenji hara" wrote in message
> news:mailman.1646.1334209001.4860.digitalmar...@puremagic.com...
>> It conflicts with ”alias this” syntax.
>>
>> template In
alue type (e.g., it's harmless for int[int].keys to return
> int[] because the int's are a copy anyway, and this way user code won't
> be unnecessarily straitjacketed to propagate immutable throughout).
>
> I'd like to hear how people think this should work, so that the new AA
> implementation will be more acceptable.
Thanks.
Kenji Hara
>> >{
>> > Bar b;
>> > b.bar();
>> >}
>> >
>> >does not work.
>> >
>> >Jens
>>
>> This is a bug. You can report it to:
>> http://d.puremagic.com/issues/
>
> It's submitted.
> http://d.puremagic.com/issues/show_bug.cgi?id=7943
> Thanks for your reply.
>
> Jens
Posted compiler fix:
https://github.com/D-Programming-Language/dmd/pull/890
Thanks for your reporting, Jens!
Kenji Hara
gt;
> Man, you're wonderful Kenji. You never cease to amaze me. Your ability
> to correct bugs is borderline incredible.
Thanks.
Kenji Hara
2012年4月23日21:36 Denis Shelomovskij :
> I've never used new excellent range formatting syntax by Kenji Hara until
> now. And I've met with difficulties, because "%(%(%c%), %)" is the most
> common format for string array for me and it neither obvious nor elegant. I
2012年4月24日1:14 Denis Shelomovskij :
> 23.04.2012 18:54, kenji hara написал:
>
>> Please give us use cases. I cannot imagine why you want to
>> change/remove quotations but keep escaped contents.
>
>
> Sorry, I should mention that !' and !" are optional and ar
2012年4月24日2:49 Denis Shelomovskij :
> 23.04.2012 21:15, kenji hara написал:
>>
>> 2012年4月24日1:14 Denis Shelomovskij:
>>>
>>> 23.04.2012 18:54, kenji hara написал:
>>>
>>>
>>>> Please give us use cases. I cannot imagine why you
2012年4月24日17:20 Denis Shelomovskij :
> On Tuesday, 24 April 2012 at 04:55:34 UTC, kenji hara wrote:
>>
>> My concern is that the proposal is much complicated and less useful
>> for general use cases.
>> You can emulate such formatting like follows:
>
>
> IMHO
aa[key] = val;
should be evaluated:
1. aa
2. key
3. val
4. aa[key] = val <-- allocating slot and set to it
Kenji Hara
2013/01/11 18:56 "deadalnix" :
> On Friday, 11 January 2013 at 08:55:55 UTC, Bernard Helyer wrote:
>
>> I completely agree. Doesn't the spec say t
I think there is no problem.
Kenji Hara
2013/1/21 Walter Bright
> The current version is pretty verbose. For:
>
> int ***x;
>
> it will emit as the type:
>
> "type" : {
> "kind" : "pointer",
> "pretty&q
Changing output data to mangled name is no problem. It provides enough
informations for the machine readable.
Kenji Hara
2013/1/21 Walter Bright
> On 1/20/2013 11:50 PM, kenji hara wrote:
>
>> I think there is no problem.
>>
>
> No problem with which scheme?
>
>
;optional parentheses" should not applied to the return object
recursively.
That means:
void delegate() foo() { ... }
void main() {
auto x = foo(); // typeof(x) == void delegate()
auto y = foo;// typeof(y) == void delegate()
}
Kenji Hara
I posted:
http://d.puremagic.com/issues/show_bug.cgi?id=9062
Kenji Hara
2013/1/25 Andrei Alexandrescu
> On 1/24/13 4:56 PM, Adam Wilson wrote:
>
>> Simplicity is clearly good, but there's something to be said about
>>> those warts in chained calls. The UFCS-enabled idioms clearly
e than
> t.baz() should call the DELEGATE, but it doesn't...
>
> Optional Parens Encourage Ambiguity. Ambiguity Fosters Bugs.
1. Optional parentheses for normal functions should work shallowly IMO.
2. Optional parentheses for property functions should not work. Applying ()
for property function name always applied to its returned value.
#1 is a ratification of current behavior. It allows the combination of UFCS
and removing redundant ()s.
#2 is a breaking change. If we need it, community consent is required.
Kenji Hara
2013/1/25 Adam Wilson
> On Thu, 24 Jan 2013 17:15:09 -0800, kenji hara
> wrote:
>
>>
>> 1. Optional parentheses for normal functions should work shallowly IMO.
>> 2. Optional parentheses for property functions should not work. Applying
>> ()
>> for prope
2013/1/25 kenji hara
>
>
> I have thought an additional idea.
> If we really want a feature to disable optional parentheses for normal
> functions, we can add @function attribute to the language spec.
>
> int foo();
> @property int bar();
> @function int baz(); // new!
1 - 100 of 448 matches
Mail list logo
