On 14/08/16 17:07, Andrei Alexandrescu wrote: > On 08/14/2016 01:18 AM, Shachar Shemesh wrote: >>> So that is slide 4. Could you please give a bit of detail? >> >> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html >> > > OK. One thing we can't stress enough is that everything - talks, slides, > newsgroup posts - about a bug in the language definition or > implementation must be in support of an issue. No issue no honey. I > submitted https://issues.dlang.org/show_bug.cgi?id=16388 on your behalf > and preapproved it. Please carry future considerations there.
Thank you. To be fair, though, you might want to close it as a duplicate of https://issues.dlang.org/show_bug.cgi?id=14246 > I understand. One thing we want to do to improve on that is to deduce > const for template methods. See > https://issues.dlang.org/show_bug.cgi?id=16389. Personally, I also think that inout should stop acting like it is a fourth form of protection. > Here again we're not talking about a bug in the language > or the "right" or "wrong" language design, it's just a matter in which > different languages do different things. > >> Also, I should point out, that I'm not suggesting D allow implicit >> narrowing conversions. Instead, I think D should drop the pretense that >> C expressions should maintain their semantics precisely, and stop >> widening expressions. > > This will not happen. I had a whole list of places where D already isn't compatible with C for a statement that compiles in both. I cannot find it. I'll start a new thread when I do. > >> I must confess that I have never heard of this rule in C before >> encountering it in D. > > Which rule? The rule that says "ubyte + ubyte = uint". >> Can you expand a little on the rational for that? > > The "ref" attribute has been a fundamental part of the language for too > long. I'm sorry, I simply don't understand that answer. How is turning "ref" into a type modifier hinder you in any way? No old compiling code breaks as a result. > >> Also, part of our >> problems with this is that introspection also does not see refs, which >> causes the following two functions to report the same signature: >> >> void func1(int arg); >> void func2(ref int arg); > > I actually think you can do introspection on any argument to figure > whether it has "ref". > >>> We'd love to make the life easier for Weka, >> >> I'd like to make it clear here that I speak of my own experience. I do >> talk with people, and some of the engineers share some of my criticism. >> However, please don't think that just because I'm more vocal than others >> in Weka, it means that my opinions are shared by all. Please treat my >> posts here as my own. > > There are some good points that we could easily agree need to be > improved. At some point you must get in gear and submit some issues to > move forward on things important to Weka. The problem is that many of those points are contended (or, at least, used to be). If you read through the thread I pointed to regarding the destructor issue, for example, you will see that people actually argue that the way D currently does things is the correct way to do things. If I submit an issue to the forum, and get back the reply "that's a know thing, and that's on purpose", I don't see any point in submitting an issue. > >> From what I understand, there is a problem with the way imports are put >> in the di files. In particular, take the following code: >> >> import some.struct: SomeStruct; >> import some.other.struct: SomeOtherStruct; >> >> SomeStruct func() { >> SomeOtherStruct a(3); >> return a.some; >> } >> >> The ideal di for it would be: >> >> import some.struct: SomeStruct; >> >> SomeStruct func(); >> >> Sadly, the actual di also contains the totally unnecessary: >> >> import some.other.struct: SomeOtherStruct; >> >> The result is that the di contains too many imports, and no gains are >> made vis compilation times. > > I think you forgot to mention the issue number :o). Like I said, I'm just a relay on that front. I'll try to get the people actually working on it to submit an issue. Shachar