Re: Installing vibe via DUB
On Monday, 10 June 2013 at 19:46:24 UTC, Jonathan M Davis wrote: You'll have to take that up with the rejectedsoftware folks. It's their forum. The main D forums are set up to use newsgroups as their backend while allowing users to also interact via a web forum and e-mail, but AFAIK, they are unique in that regard. So, I wouldn't expect anyone else to be doing that unless they used the same software - which the rejectdsoftware folks could do, but it's up to them. On a related note, I believe that Vladimir was looking making the main D forums' software use vibe.d, but I don't know where he is with that. - Jonathan M Davis Vibed.org forums are similar but use own vibe.d-based front-end instead of DFeed.
Re: On the subject of properties, and possibility of having them in the library
Reason why library properties are not that usable is simple: typeof(A._n) must be same as typeof(A.n) or this is not really a property. Please take a look at examples and arguments in wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up
Re: D for scientific computing
On Saturday, 26 January 2013 at 15:17:18 UTC, Joseph Rushton Wakeling wrote: ... ++ Once situation with front-end bugs and stability is settled, I see zero reasons to use dmd back-end and spending efforts on its optimization feels not pragmatical.
Re: D for scientific computing
Yes, of course, we all have our own preferences, that is fine :) I mean a bit different thing: front-end efforts affect all major compiler lovers, not only one group and thus are more important.
Re: Its me
On Saturday, 26 January 2013 at 16:42:13 UTC, Tyro[17] wrote: http://commons.wikimedia.org/wiki/File:US_Navy_070313-N-0120A-146_Staff_Sgt._Andrew_C._Edwards_polishes_the_American_flag_on_a_Marine_Corps_memorial_for_the_veterans_of_the_battle_for_Iwo_Jima_on_the_top_of_Mount_Suribachi.jpg Cheers!
Re: Incorporating D
On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote: On 2013-01-26 20:55, SomeDude wrote: AFAWK, at least one major videogames studio is writing its new title in D. For real? You must be joking. :) Tsss, it is a secret ;)
Fixing module-scope private
There was discussion recently about unpleasant name conflict possible with private module symbols. I have just encountered a sarcastically false statement on dlang.org : Private module members are equivalent to static declarations in C programs. Made me sad and wondering: was there any DIP after that thread or it has ended, as it often happens, with a decision to plan carefully? In latter case I may try to write one.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 22:45:52 UTC, Walter Bright wrote: Having a release process does not remove the pain of breaking changes that make users miserable because their older code no longer compiles. Beg my pardon, it is very ignorant position. It assumes user is some kind of stubborn creature that is scared of any spec changes. But it is not really the case. Users are not afraid of compiler release breaking their code - they are afraid of not having a single compiler version that both is stable enough and works for their code. And that it is very different. It is fine to break code in release if you still provide bug-fixes to some older version that may be recommended for usage until time to fix code base is taken. And this is exactly where good release process shines, it is single most important reason to have it. To sum up my position: 1) D spec is imperfect 2) Breaking change are inevitable 3) Saying breaking changes are bad means hiding the problem 4) It is better to focus on process to minimize breaking changes damage than rant about how bad they are 5) Leaving feature badly designed for years with no hope to change is worse than breaking code. I'd really like to read your position on _all_ of those statements, because we are running circles here.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 21:23:53 UTC, Andrei Alexandrescu wrote: ... Sorry Andrei, with all my due respect, you have a brilliant talent to answer something without actually stating any own position on topic. Please take a look to my answer to Walter: http://forum.dlang.org/post/lpdegnaygbiijuwdd...@forum.dlang.org I'd really like to understand your position too, because arguing about sentences leads nowhere.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 09:49:29 UTC, Don wrote: ... ++ It feels that breaking code has become some kind of scary ghost that is just being afraid of instead of some kind of analysis-based approach.
Re: @property - take it behind the woodshed and shoot it?
Also I need to remind you that we break code all the time with big fixes, literally every release. And end user does not care how reasonable breaking it is, they are all the same: time needed to update the code base. We need to admit that breaking is inevitable and go forward from there to fix real solvable problems.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 05:35:19 UTC, kenji hara wrote:
module abc;
@property int foo(int n);
void main() {
foo = 1; // top-level property setter
1.foo; // property getter with UFCS
}
We cannot distinguish the two usages without adding any new
features.
Kenji Hara
1.foo must be compile error here. Makes as much sense as
int a;
void main() {
1.a;
}
Property must behave exactly like data or it is not a property.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 10:26:14 UTC, Robert burner Schadek wrote: ... Yes, the syntax is legit. It's the semantic that scares me. IMHO it feels strange that assigning a variable resizes a array. Something like a.resize(10) would make me feel better. Ye, it was one of the first Erm wtf? moments when I started to learn D. And living confirmation that core developers don't really have a strong vision what properties should be.
Re: @property - take it behind the woodshed and shoot it?
Why? Other than breaking code.
Re: @property - take it behind the woodshed and shoot it?
OK, it has become difficult to follow all thread (newsgroups are not that perfect for this), so I will do tl; dr in a form of I final proposal. Basic statement 1: Breaking user code is inevitable Basic statement 2: Special cases are indicators something wrong is with design Basic statement 3: Data is not function. Function is not data. (Sorry, John von Neumann!) Property is data. Proposal itself: *) -property flag becomes no-op *) parens for all callables are mandatory *) parens for properties are prohibited *) properties are always treated to be of type of their return data *) As a consequence - in UFCS property always behaves as a parameter, never as function Transition issues: *) Before merging new behavior to master, staging is created from last backwards-compatible. Official announcement is made that it will be bug-fix supported for at least 6 months. *) Meta bugzilla issue is created to make Phobos code more strict in this regard. Release with new behavior will be allowed to go to staging only after this issue is taken care of. *) All property-related issues that ensure data-like behavior like += are marked as preapproved. And yes, I know that Andrei has already made his decision about optional parens and this is also a no-op. But oh well.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 13:18:47 UTC, Jacob Carlborg wrote: On 2013-01-25 10:16, deadalnix wrote: Assignation is right associative, so it is equivalent to : auto i = (f = 3); The setter is called. That's what I'm saying, the setter needs to be able to return something and not just void. Hm, shouldn't it be processed like that: 1) evaluate f = 3, setter called 2) evaluate (f = 3) - evaluate f - getter called 3) evaluate auto i = , setter called ?
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 13:52:37 UTC, Jacob Carlborg wrote: On 2013-01-25 14:26, mist wrote: Hm, shouldn't it be processed like that: 1) evaluate f = 3, setter called 2) evaluate (f = 3) - evaluate f - getter called 3) evaluate auto i = , setter called ? Yes, but why would a setter be called at step 3? Was thinking about i setter, did not pay attention it is actually a new declaration :) Never mind.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 14:18:43 UTC, TommiT wrote:
I don't see 1.foo the way you see it. I see it like this:
@property bool is_zero(X value)
{
return value == 0;
}
void main()
{
X value;
value.is_zero;
}
It's just that X happens to be a built-in type, instead of a
user-defined type. But I don't see why should that matter.
It is a tempting attempt to save two symbols of typing that
completely breaks property semantics. I am objecting against it.
With all my passion.
Use value.is_zero() for UFCS magic.
Re: @property - take it behind the woodshed and shoot it?
Meaning of @property for free functions is well-defined. Most likely because languages like C# does not have UFCS as far as I rememeber. I see two possible approaches here: 1) - @property void symbol1(Data); @property Data symbol1(); Data symbol2; ... symbol1 = symbol2; // allowed, symbol1 behaves same as symbol2 for user symbol2.symbol1; // prohibited, symbol1 is semantically a global variable - 2) - @property void symbol1(Data); @property Data symbol1(); Data symbol2; ... symbol1 = symbol2; // prohibited, symbol1 has meaning only within UFCS and imitates Data member. symbol2.symbol1; // Fine, rewritten as symbol1(symbol2), follows general property rules but for compound symbol - First one seems more natural to me, but I can live with either approach. Not both. Also please mote that UFCS is meant for enhancing data type functionality with free functions, not implementing every possible feature available to that data type with native syntax.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 15:02:46 UTC, Jacob Carlborg wrote: On 2013-01-25 15:55, mist wrote: Meaning of @property for free functions is well-defined. Most likely because languages like C# does not have UFCS as far as I rememeber. C# doesn't have UFCS but it does have a syntax for adding new methods for existing classes. The end result is the same. Great, could you give a sample? Does it work on compile time or injects in run-time? Is calling of such methods allowed in usual free form? Unfortunately I have never been using C# in practice, only following materials available in the internet, would be really interesting to learn from their approach.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 15:05:11 UTC, deadalnix wrote: See what is proposed here : http://forum.dlang.org/thread/kdqrnl$13ft$1...@digitalmars.com?page=3#post-uagknsecziepoedcabvr:40forum.dlang.org Looks somewhat solid to me, with some disagreement on UFCS side :) Will reply with comments to that post.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 15:13:21 UTC, Jacob Carlborg wrote:
The secret is to add this in front of the argument type you
want to the method to extend:
namespace ExtensionMethods
{
public static class MyExtensions
{
public static int WordCount(this String str)
{
return str.Split(new char[] { ' ', '.', '?' },
StringSplitOptions.RemoveEmptyEntries).Length;
}
}
}
using ExtensionMethods;
string s = Hello Extension Methods;
int i = s.WordCount();
http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx
Good. Main questions remain though: is property syntax allowed on
extension methods? Is WordCount(s) call allowed?
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 13:41:42 UTC, deadalnix wrote:
For regular functions :
1. funName is the function itself :
void funName() {}
static assert(is(typeof(funName) == void function())); //
Pass.
funName has no address, it is equivalent to enum function
void() funName = {};
funName become a NOOP and is deprecated, for compatibility
reasons. It is not ambiguous as funName has no address anyway.
Agree with differentiation but why no address? For me funName
looks like function pointer variable, why prohibiting to cast
this to raw address? funName is legacy, agree.
2. funName() call the function.
And if funName is a getter returning delegate?
3. @getter is an attribute. A function marked @getter is
automatically executed : () is added automatically :
@getter void funName() {}
funName; // function get executed.
funName(); // Error, void is not callable.
Agree, but @property is enough. I ll insist below that ambiguous
cases should be simply an error. And I'd also like to prohibit
getters returning void ;)
4. @getter can be used as UFCS.
@getter void funName(T t) {}
T t; t.funName; // function gets executed.
funName(t); // Error, funName require 1 argument, 0 given.
Fine by me, but error message is weird. Better Error, funName is
not usable with free-from syntax.
5. @setter is an attribute. A setter method can *only* be used
in rhs of an expression. The assigned value is used as argument.
@setter void funName(T t) {}
T t; funName = t; // function gets executed.
funName(t); // Error, funName must be used in an assign
expression.
Disagree, it is inconsistent with getter. @property ...
funName(T t ... ) should always behave as t.funName property. It
is unnecessary complication.
6. @setter can as well be used as UFCS :
@getter void funName(T t, U u) {}
T t; U u; t.funName = u; // function gets executed.
t.funName(u); // Error, funName must be used in an assign
expression.
And this is exactly the syntax I'd like to see. Again, as void
return should be disallowed for getters, no ambiguity here and
same @property suits just fine.
7a. A function can be defined as both @setter and @getter, and
cumulate both behavior.
Feels like unnecessary complication. But if you want to, simply
having both return type and 2 parameters is enough.
7b. @property is deprecated and redefined as @setter *and*
@getter for a transitional period.
;)
8. method behave as functions :
class A { void foo() {} }
A a;
static assert(is(typeof(a.foo) : void delegate())); // Pass.
a.foo; // deprecated NOOP for compatibility.
a.foo(); // call a.foo
Agree;
9. UFCS without () are delegate like construct :
10. To allow chain of UFCS calls without () everywhere, an
opDispatch is defined in object.d
Very complicated for no real gain. Just prohibit function call
without (), including (). Profit!
Waiting for the shitstorm . . .
Welcome ;)
Re: vibe.d
On Friday, 25 January 2013 at 15:18:08 UTC, Russel Winder wrote: Is the vibed.org website non-functional? Ye looks like it has some stability issues. Or frequent maintenance :) Down for me once in a while, today too.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 15:57:16 UTC, deadalnix wrote: No adress because : - it would now be impossible to ensure transition using as NOOP. - this address is useless anyway. That'd be a pointer to a pointer to instructions. Need to think about it. funName is not a getter and don't return a delegate. How a getter behave is explained below. Mixing everything together is the perfect way to create a mess. Well, but it is were good design vs mess of special cases really shines :) Anyway, in this statement by function you mean non-property function, ye? You didn't addressed why @property. Answer you gave to point 5 and 6 make me think you aren't aware of the ambiguities @property causes with UFCS. Please note that : [1, 2].front and front = [1, 2] are semantically 100% equivalent. Not really as I see it. [1, 2].front // requires signature @property T front(int[]) front = [1, 2] // compile error arr.front = [1, 2] // requires signature @property void front(T, int[]) The above code is rewritten ad funName()(t) . Ah, _now_ I am starting to get your proposal. And do not like it in that regard. Many people here disagree. I tend to be amongst thoses people. This specific case imply no ambiguity, and is similar to other simplification D already make like . dereferencing pointers. Well, then it is probably best to focus on free-form property semantics and leave argument about optional parens and friends - there were enough of them in this topic ;) I'll push for optional ones to the end but hope at least for the solution where ambiguity is consistently resolved.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 16:29:40 UTC, deadalnix wrote: So you DO make a difference between setters and getters. Yes, sure. But I do not need new keywords for that. funName(t) is valid if funName returns a delegate. The compiler shouldn't even try to interpret funName(...) as a call of funName. Yes, I have finally understood how it is intended to work. I just do not like complexity with re-writing funName(t) as funName()(t) and hidden struct creation from function symbols. I cheer any compiling restrictions, but overall type system should be as transparent as possible for normal cases. Like brutal simplicity of my proposal better :) But it is an interesting approach, thank you for the insight.
Re: vibe.d
On Friday, 25 January 2013 at 16:48:47 UTC, eles wrote: On Friday, 25 January 2013 at 15:18:08 UTC, Russel Winder wrote: Is the vibed.org website non-functional? It's just you. http://vibed.org is up. Because you are a slowpoke :P Missed all the downtime fun ;)
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 16:53:43 UTC, deadalnix wrote: Because you invalidate most legitimate use of a setter. Erm.. Whaaat? How this case is legitimate at all? Please elaborate. In example you define a @property for some data type and then try to assign to this property without using any context. It is like calling class method and skipping this. As I have mentioned in other thread, there are 2 contradictory approaches: either free-form property has semantics of global variable or it has semantics of data member of its first argument. Not both. A struct with a function pointer and data already exists in D. This is called a delegate. And additional hidden implementation complications differ it from all other function types. Rare special case for clearly defined situations. I like it that way. Leave function to be just like good old C function.
Re: Make dur a property?
On Thursday, 24 January 2013 at 23:11:25 UTC, Timon Gehr wrote: This is not C#. Ye, exactly. Contrary to C#, our properties suck.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 18:41:46 UTC, H. S. Teoh wrote: ... Sound base that avoid discussion of controversial topics :) Looks like I can agree with almost everything. Probably even everything. Only thing that needs to be defined is @property on free-functions: disallow, treat as global variable or treat as an extension methods. We has small discussion on this topic with deadalanix afair somewhere up the topic.
Re: Property discussion wrap-up
Good. That thread has already been huge by morning, it is rather hard to find essential info there now.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 19:30:26 UTC, Jonathan M Davis wrote: ... I am not going to argue anything, I am just asking _how_ they are supposed to work, what are exact semantic. I have added various syntax cases to wiki: http://wiki.dlang.org/Property_Discussion_Wrap-up#.40property_on_free_functions What I am going to argue is if all of those example are supposed to work. We can't define property semantics to be just like data when property symbol can't be just interchanged with data symbol. From the syntax point of view no issues there.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 19:54:29 UTC, Nick Sabalausky wrote: I think you might have misunderstood it. What he's trying to do is use UFCS to add a property to a type instead of adding a function. I got it. What I am questioning is that allowing this in some way is a must. And somewhat changed my mind after that :) There is semantic ambiguity here currently (rules are too lax) that I have described in wiki http://wiki.dlang.org/Property_Discussion_Wrap-up - and I pretty much like proposal there.
Re: @property - take it behind the woodshed and shoot it?
Finally, stating some opinions clearly. Thank you.
Re: Property discussion wrap-up
I have added a basis for quite an important thing (in my opinion) - unified test code base that covers as much possible (and impossible) usage, with all weird cases. Any new proposal can then be clearly defined by how it processes this code and what defines legals. And later this will can be trivially converted into unittest.
Re: Incorporating D
On Friday, 25 January 2013 at 20:50:22 UTC, Szymon wrote: That was fast :) Not thrilled about the answers to ;) Well, I'd say application-level server side it is quite fine with one big OOPS: your company needs to be ready to spend certain time to maintain compiler yourself. In other words it is somewhat stable in sense it is not likely to meet broken code gen and is more than possible to code something neat. But you can't just take it and use it out of the box.
Re: Property discussion wrap-up
How about separating actual proposals to own pages? One more and this will become a mess.
Re: @property - take it behind the woodshed and shoot it?
2 cents regarding your position on @property usage in phobos: 1) You can always use shorter syntax: @property: int func1(); int func2(); ... 2) D is not scripting language (primarily) and as such should value issues related to long-term large code base support more than saving some typing in declaration. It is slightly similar to strong vs weak typing. That is not gonna convince you but I hope this will be taken into consideration somehow.
Re: @property - take it behind the woodshed and shoot it?
On Friday, 25 January 2013 at 22:15:51 UTC, Jonathan M Davis wrote: They both already work and have do so for ages. - Jonathan M Davis Erm? Yes, and thus it was an answer to you need to mess every function declaration with an annotation
Re: Incorporating D
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
So structs in D are always passed by-value? That is
unfortunate...
No, that is what he speaks about:
struct SomeStruct
{
int a, b;
}
void f1(ref SomeStruct input) { }
void f2(const ref SomeStruct input) { }
void main()
{
SomeStruct a;
f1(a); // fine
f2(a); // fine
// f1(SomeStruct(0,0)); // invalid, predictable
// f2(SomeStruct(0,0)); // invalid, surprise to C++ guys
}
Re: @property - take it behind the woodshed and shoot it?
I am probably I minority here but I liked the most strict -property version and it made a lot of sense to me. Rationale is simple: some().ufcs().chaining(); - this is just a minor syntax inconvenience anything; - this drives me crazy, there is no way to understand if this a no-op statement variable of function call with some side-effect I'd really like to have all function types to be obliged to use () and use property syntax only to those of property semantics (no side-effect variable getter/setter) But looking at other comments this does not seem popular :( Well, I can only hope for something simple and non-revolutionary then.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 12:53:45 UTC, Jacob Carlborg wrote: On 2013-01-24 13:35, bearophile wrote: Instead of adding a -property, why wasn't this done since the beginning? It would break tons of code. And yet it must have been done at some point. With some year-ahead announcement or anything like that, but it was a horrible design error in first place which needs to be fixed.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 13:34:08 UTC, Artur Skawina wrote: On 01/24/13 12:50, mist wrote: But looking at other comments this does not seem popular :( Language design is not a popularity contest. artur Well most discussions seems to flow around simple preference conflict of beautiful UFCS vs consistent function calls. And all compromises tend to explode in difficulty once delegates and function pointers are taken into consideration. I find consistent and unambiguous call syntax more important.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 13:43:41 UTC, Jacob Carlborg wrote: On 2013-01-24 14:01, mist wrote: And yet it must have been done at some point. With some year-ahead announcement or anything like that, but it was a horrible design error in first place which needs to be fixed. Yes, it was a horrible design error but it didn't break any code because the -property flag is optional. Design error was to not force -property since the very beginning. Now good decisions are kind of doomed to break code because restrictions were (and still are) too lax and a lot of inconsistent code is somewhere out there. This is exactly why I voted for LTS + rolling-release model. D is still far from the point where design specs can be frozen and breaking code prohibited. Those still have mistakes.
Re: Global immutable AA literals
Googling is so good for necro thread resurrection.
What is idiomatic way in D to initialize static immutable AA to
be accessible in CTFE at the same? static this() won't help here,
unfortunately.
On Wednesday, 9 November 2011 at 10:44:08 UTC, Gor Gyolchanyan
wrote:
I think this is a bug and i even recall seeing it in bugzilla,
but i
don't have a link to it.
On Wed, Nov 9, 2011 at 10:43 AM, bearophile
bearophileh...@lycos.com wrote:
Is it possible to modify DMD to allow a program like:
immutable int[int] aa = [1:15, 2: 7];
void main() {}
With the latest DMD it gives:
test.d(1): Error: non-constant expression [1:15,2:7]
Global immutable associative arrays are handy in script-like
programs, I use them now and then in Python (despite they are
not immutable).
This is a workaround for script-like programs, that I
sometimes use:
immutable int[int] aa;
static this() {
aa = [1:15, 2: 7];
}
void main() {}
But when possible I try to avoid using static this.
Bye,
bearophile
Re: Global immutable AA literals
You know what? Screw idiomatic. Is there _any_ way to use a compile-time associative array literal?
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 17:49:18 UTC, Andrei Alexandrescu wrote: On 1/24/13 6:50 AM, mist wrote: I am probably I minority here but I liked the most strict -property version and it made a lot of sense to me. Rationale is simple: some().ufcs().chaining(); - this is just a minor syntax inconvenience It becomes way uglier with templates: some!(e1)().ufcs!(e2)().chaining!(e3)(). In fact look at the code written by Nick in _favor_ of the parens. Self-destruction at its finest. I can hardly see any problems in your code sample. Syntax inconvenience means nothing when compared to semantic inconvenience. It is just matter of visual preferences after all, you can get used to it quite fast. anything; - this drives me crazy, there is no way to understand if this I was amazed at how quickly I got used to it. ... You'll still be able to use parens. Andrei You see, contrary to UFCS chaining this is not habit or syntax issue. It is semantic one - I am loosing an ability to distinct data access from function call by simply looking at code. There is nothing I can get used to - in a sane design I have this info, in D I do not. You have been just shown a few very good examples regarding functions, returning delegates - it is exactly the case where it shines. Yes, I am able to use parens, but in _my_ code I also do not need -property or anything - I am C++ programmer after all, I can discipline myself to certain code style even without compiler help. But writing generic code and reading one of others... I am glad I have not had to do any high-order function generic processing yet.
Re: @property - take it behind the woodshed and shoot it?
One thing I am interested to hear from ones who think allowing
no-parens calls is fine is the following snippet:
http://dpaste.1azy.net/cd2f759e
import std.stdio;
alias Delegate1 = int delegate();
alias Delegate2 = Delegate1 delegate();
Delegate2 func()
{
writeln(Function);
return (){
writeln(First delegate);
return (){
writeln(Second delegate);
return 42;
};
};
}
int call(alias func)()
{
return func;
}
void main()
{
writeln(Case 1);
func;
writeln(Case 2);
func();
writeln(Case 3);
func()();
writeln(Case 4);
auto tmp = func();
// tmp; // Error: var has no effect in expression (tmp)
}
Upon any design choice questions should asked:
1) How this should behave to be consistent?
2) Should this error be an error?
3) How much special casing are you ready to throw in?
Also I really like an addition with prohibiting to use @property
functions _with_ parens. Add this to prohibiting no-parens calls
for normal ones and you will get my ideal solution, strict and
clear.
And I still don't see why it won't fly. Yes, it will break user
code. No, this is not an issue. At this point it is clear some
design mistakes need to be corrected without stockpiling
workarounds and one of major goals for new release process was to
allow breaking changes with least possible user inconvenience. If
it is not the case, then new release process has failed as much
as @property.
Re: Global immutable AA literals
Thank you. So simple and so illogical. Looking at your example I
have zero understanding why AA literals just do not work at
compile-time just out of the box.
On Thursday, 24 January 2013 at 19:30:27 UTC, Artur Skawina wrote:
On 01/24/13 19:36, mist wrote:
You know what? Screw idiomatic. Is there _any_ way to use a
compile-time associative array literal?
template ctAA(alias aal) { enum ctAA = aal; }
enum aa = ctAA!([one:1, two:2]);
int main() {
enum x = aa[two];
pragma(msg, x.stringof);
return x;
}
artur
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 20:00:18 UTC, Andrei Alexandrescu wrote: On 1/24/13 1:35 PM, mist wrote: You see, contrary to UFCS chaining this is not habit or syntax issue. It is semantic one - I am loosing an ability to distinct data access from function call by simply looking at code. This is the case with any property implementation. Andrei Not really. Good property usage is somewhat similar to unsafe cast usage - you say to others Yes, I know what I am doing, please do not pay attention that this data is in fact function. The very point of properties is to be used almost indistinguishable from data and if this usage pattern fails - property author has lied and this is not really a property. And because of issues like += it is rather difficult (if possible) to define good properties in D now.
Re: Global immutable AA literals
Ah, I get the trick - enum does not really hold an AA, it is just a copy-paste entity. Change the aa from enum to immutable - and it won't compile.
Re: Global immutable AA literals
Sorry, no offense meant from my side :) I have followed your attempts on github and do not really feel in shape and competence to try to add anything there now. I simply could not understand why assignment to enum works and to immutable - not. Then remembered they enums are simply replaced with literals again and again every time when used and got it. On Thursday, 24 January 2013 at 20:10:21 UTC, H. S. Teoh wrote: Because the current AA implementation sucks. You're welcome to try to improve it. I've tried before, but it's non-trivial because it's schizophrenically split across two places in druntime and sprinkled all over the compiler. Good luck. Should you succeed, you will have done a MAJOR favor to the entire D community (Andrei, for one, will be eternally grateful). T
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote: Let's consider what a property really is. It's a data encapsulation tool. They allow us to expose object internal data in a safe way. Nuking the idea is a step backwards. This, this and this again. Reading this thread I sometimes get the feeling that part of programmers treat property as a nice way to save 2 extra symbols. Or probably to play with verb/noun meaning. It has different goals from both of those.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 20:44:33 UTC, eles wrote: On Thursday, 24 January 2013 at 20:26:50 UTC, mist wrote: On Thursday, 24 January 2013 at 20:20:42 UTC, Adam Wilson wrote: I think the widest spread use case of a property is: you start with a variable as memeber of a class, you write a lot of assignment code, then you decide that you need to do some more extensive processing instead of simple assignment, and all that without breaking existing code. so, you transform the variable into a property. of course, it could happen the other way around (converting a function into a property/variable). It is a wrong use case for a property. Necessity to change data assignment/access to call of function with side-effect is design error and should be fixed with programmers experience, not property hacks.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 20:52:10 UTC, Walter Bright wrote: On 1/24/2013 5:42 AM, Jacob Carlborg wrote: I agree with you but Walter is very afraid of breaking code. The history of what happens when D code breaks because of language changes is not a happy one. ragePlease. Go to http://wiki.dlang.org/Release_Process . Read it. Answer the question Hm, does having well-defined release process with long-term support versions help with instability of breaking changes?. And if answer is no then you probably should have contributed your opinion there for a long time, because it _should_ to./rage Really, all this backwards-compatibility talk is a crap. There is no way we can say current D design is final and solid and can be polished without any breaking changes. We should not argue about how bad breaking is. We should discus how to do those changes in the least harmful way.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 21:00:32 UTC, Andrei Alexandrescu wrote: On 1/24/13 3:58 PM, mist wrote: Really, all this backwards-compatibility talk is a crap. There's just a lot of evidence that suggests the contrary. Clearly we don't want or like to be conservative, but apparently we need to. Andrei Do you read and answer only to the first sentence? Can you honestly say D design is rock solid and correct, we will never be required to make any backwards-incompatible change? If you check those evidences, it was never breaking code alone. It was breaking code AND lack of any sane process that allows to stick with acceptable release version for longer time. And I suggest to fix the right thing, not freeze specs and hope all problems will fade themselves.
Re: @property - take it behind the woodshed and shoot it?
On Thursday, 24 January 2013 at 21:00:49 UTC, Jonathan M Davis wrote: Being able to swap out a public variable with a function without having to change any code using it is arguably the primary reasons that property functions exist in the first place. ... Yes, but not just any function. Side-effect free function that controls access to data. And Adam suggested it is fine to use properties to add side-effects to data assignments which is drastically different. I agree with all your words so it is probably just misunderstanding.
Re: @property - take it behind the woodshed and shoot it?
%s/Adam/eles/g
Re: Global immutable AA literals
On Thursday, 24 January 2013 at 21:12:41 UTC, H. S. Teoh wrote: I didn't take any offense. Just stating that AA's as currently implemented leaves a lot to be desired, and it's not going to improve unless *somebody* takes up the challenge to fix it. Sure. But there are so many yummy bugs and issues hanging around D, it is so hard to chose among them :) By the way, could you provided a link to the your latest pull request on topic and related discussion? I remember seeing something in github notifications but can't find right now.
Re: Pull 1019
yebblies: Can an auto-ref function pointer/deltegate implicitly convert to ref? 9rnsr: To @yebblies : I yet not implement it because this is a basic proposal. IMHO, what he says is that behavior proposed by yebblies is some more complicated special cases he is not going to do within this pull request to keep things simple. All pulls are proposals, by the way, it is up to one of core devs (other than pull author) to make a decision about merging. On Wednesday, 23 January 2013 at 23:46:19 UTC, Namespace wrote: I have now seen something I've probably overlooked before. Here: https://github.com/D-Programming-Language/dmd/pull/1019#issuecomment-11836011 Kenji says, that the pull is a basic _proposal_. What does this mean? It isn't merged until we made a final discussion and decision about that? :/ I thought that this is the solution for all C++ rvalue ref problems. Am i wrong? I'm asking so much because I've been using it already - and I love it. Without such thing it is very annoying to work with structs.
Re: Getting the parameters of a struct/class constructor
You can use magic functions __ctor and __dtor which actually serve as constructor and destructor implementations behind the scene. Example and proof-of-concept: http://dpaste.1azy.net/fd924332 Have no idea if it is explicitly defined by spec somewhere though.
Re: Scope and with
On Wednesday, 23 January 2013 at 10:43:24 UTC, simendsjo wrote: On Wednesday, 23 January 2013 at 10:30:08 UTC, Namespace wrote: But AFAIK scope isn't fully implemented as storage class, or am I wrong? I think you are right. And I think it's the reason using 'in' parameters are discouraged. I remember Kenji telling in currently is synonym for const, not const scope as is often told.
Re: Mono-D v0.4.9 - Rough formatting capability
On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
Re: Mono-D v0.4.9 - Rough formatting capability
I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab-space autoreplacement for external editors. In-place formatting is not that important for me. On Tuesday, 22 January 2013 at 14:44:15 UTC, alex wrote: On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote: On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote: On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote: Thanks Alex, even though I don't use auto-formatting (I never did like that). I use it rarely either - but some others asked whether I could do this - and now there it is :) Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this! Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Re: Why D is created?
On Tuesday, 22 January 2013 at 10:20:57 UTC, MMj wrote: Hello Dennis. Thanks very much for your guidance. Yes I'm a C\C++ programmer. Are you an expert in D? Why you thought C\C++ not good? Wow, are we looking at C++ programmer who considers C++ good? :)
Re: randomSample does not accept char[]
Short answer: unicode Long answer is here: http://dlang.org/phobos/std_range.html#.hasLength , please pay attention to narrow string paragraph. (failed constraint is hasLength!char[]) int is = dchar so no issues for int.
Re: randomSample does not accept char[]
This is a good hint, by the way, that something needs to be done about constraint error messages or we are risk to fallback to C++ world of pretty template library errors. I usually just go straight to template sources to save some time but that is hardly expected from a newcomer.
Re: Some dynamic dispatch to reduce template bloat
On Tuesday, 22 January 2013 at 11:09:05 UTC, bearophile wrote: This Dynamic dispatch section of the Clay language documentation shows a way to avoid some template bloat (that is common in Clay): https://github.com/jckarter/clay/wiki/Avoiding-generic-programming-pitfalls Maybe it's possible to make that syntaxcode shorter and lighter. Bye, bearophile May be I do not get it, but this can already be done in D. There is always a trade-off between template binary bloat and performance penalty of dynamic typing and suggested approach (make a templated light interface and code most function using dynamic typing) is not that uncommon one even in C++ world.
Re: Some dynamic dispatch to reduce template bloat
What syntax sugar do you propose? There is hardly anything in the link that can't be done with current std.variant.Algebraic at first glance. Only stuff I can think of is some convenient way to retrieve strongly typed value from Algebraic back, but that is library update, nothing to do about language syntax.
Re: Trust about D programming.
Well, porting druntime is not exactly the thing I can call support from GDC, it is somewhat orthogonal from compiler. On Tuesday, 22 January 2013 at 13:55:05 UTC, Freddie Chopin wrote: On Tuesday, 22 January 2013 at 13:50:51 UTC, Iain Buclaw wrote: That's a common misconception. Other platform support are already appearing (ARM, MIPS, PPC), it just requires users who have the hardware and knowledge to port the D runtime over. That's what I meant (; A small misunderstanding [; 4\/3!!
Re: Trust about D programming.
Please do, looking forward to watching video about how I am wrong :) On Tuesday, 22 January 2013 at 14:29:11 UTC, Iain Buclaw wrote: On 22 January 2013 14:02, mist n...@none.none wrote: Well, porting druntime is not exactly the thing I can call support from GDC, it is somewhat orthogonal from compiler. I could argue the toss, but I'm instead going to have talk about why you are wrong... in May perhaps... :o)
Re: Some dynamic dispatch to reduce template bloat
On Tuesday, 22 January 2013 at 14:39:58 UTC, bearophile wrote: mist: What syntax sugar do you propose? Maybe some tagging to denote what template arguments should be autoboxed? The last piece of code in that page shows two saveClient() functions. Maybe only one of them is needed, and the other can be auto-generated. Bye, bearophile So far not convincing, do not see a lot of added value for new syntax :) Thanks for your explanations anyway.
Re: Pull 1019
On Tuesday, 22 January 2013 at 09:29:07 UTC, Namespace wrote: On Friday, 18 January 2013 at 13:13:03 UTC, Jacob Carlborg wrote: On 2013-01-18 14:07, Namespace wrote: Despite the danger that this annoy you probably: What about pull 1019 (https://github.com/D-Programming-Language/dmd/pull/1019)? I'm still quite new with Git so I do not know exactly what 1 Fail, 9 Pending means (and why it stands there so long) It means that the test suite failed. You can click Details to get more details about what failed. Ok I observe the pull been a while and have to say that the status is always the same: 1 Fails, 9 Pending. I also see that it is updated every few hours, but the status is still the same every time. Is this normal? Is that automatically update accordingly? And how is such a nice test environment integrated into a pull request? It will remain the same until author of the pull request will actually take time to fix test errors or whatever fails there. AFAIR Brad is the one who should get most gratitude for that nice CI suite.
Re: DConf 2013 Call for Submissions: deadline on January 28
Btw, would someone from wiki contributors be interested in doing the small talk about new planned release development process? I'd really like to see it widely recognized.
Re: Focus
C++ does not have UFCS. It does matter.
Re: D popularity
What is best in my opinion - you can start to add tests even to projects that do not yet have them, without any build system tweaks or arguments about what unit test library to use. This makes it a habit - a good habit. Before D, I never wanted to write unittests. They were cumbersome, required diversion from the task at hand, consumed extra effort, and were troublesome to remember to run separately every time you make some changes. D's unittest blocks singlehandedly converted me. :) T
Re: Operator overloading question
Do you want to discuss it? :) I have noticed that phobos style
guidelines favor constraints heavily over static asserts but this
exactly the example when I am uneasy about such choice: static
assert can both provide more user-friendly error message here and
remove some code duplication.
On Monday, 21 January 2013 at 12:27:35 UTC, bearophile wrote:
Nathan M. Swan:
The correct keyword is opBinary, not opbinary.
The compiler must give an error message easy to understand in
similar wrong cases.
http://dpaste.1azy.net/b73ef2cd
This is your code:
Arithmetic opbinary(string op)(Arithmetic rhs)
{
static if(op == +) return add(rhs);
static if(op == *) return mul(rhs);
else static assert(0, Operator ~op~ not implemented);
}
I like to add template constraints, where possible:
Arithmetic opbinary(string op)(Arithmetic rhs)
const pure nothrow if (op == + || op == *)
Bye,
bearophile
Re: Operator overloading question
Hm, but why can't static assert provide an instantiation trace? I
can live without error message but duplicating same condition
twice (one time being part of implementation) hurts my eyes :(
On Monday, 21 January 2013 at 17:16:22 UTC, Ali Çehreli wrote:
On 01/21/2013 08:32 AM, mist wrote:
phobos style
guidelines favor constraints heavily over static asserts but
this
exactly the example when I am uneasy about such choice:
static assert
can both provide more user-friendly error message here and
remove some
code duplication.
Agreed but there is a problem with 'static assert' in the
implementation: We don't know what user code has caused the
issue. (It is a common problem in C++ templated libraries that
a hard-to-understand compilation error is produced from inside
a library function template.)
D's template constraints move the compilation error to the
exact place of the user code.
void foo(string s)()
if ((s == hello) || (s == goodbye))
{
// ...
}
void main()
{
foo!howdy(); // -- compilation error on this line
}
It is better:
Error: template instance foo!(howdy) foo!(howdy) does not
match template declaration foo(string s)() if (s == hello ||
s == goodbye)
To be honest, it is kind of obvious in this simple case but
sometimes the cause of the error is still hard to understand
even with template consraints.
Ali
Re: Operator overloading question
On Monday, 21 January 2013 at 18:53:08 UTC, Ali Çehreli wrote: ... Can you elaborate. I don't see the duplication. Ali First we check that parameter is one of allowed ones in constraint. Then we do the very same check using the very same operator list to actually make a right dispatch. Looks wrong to me, we shouldn't need to. I need to clarify though: I am perfectly aware that constraints are superior solution in many cases, especially when it comes to multiple overloads for library snippets. But exactly in given example static assert feels as better suited.
Re: Exceptional coding style
Well, initially it was just a harmless joke about some unique D features. It is digitalmars.D newsgroup after all, no idea why you have taken this so seriously. But well, if you want to take this seriously, then I need to state that I can't agree with Only if the increase in ugliness is worth the ease of editing.. Prevention of copy paste is always worth any additional ugliness or incomfort it brings to programmer. Because as programmer count and program support lifetime grows any copy-paste is almost doomed to become a bug. And ugly code is just ugly. Being ugly is not a bug. I am using C-macros of preventing copy-paste all the time, by the way, when coding plain C. This is our general team policy. And despite C macros are so bad, in the end of the day it is still worth it. It is sometimes a rather complex task of using generic toolchain properly, though - I am sad that because of widespread prejudice overall average level of meta-programming culture is rather low and can result in what you have called MyClassOperatorMixinTemplate.
Re: UDA syntax
UDAs very design point is to never change type they are attached to. If you want to inject code in a class/struct at compile-time, template mixins are supposed tools.
Re: DConf 2013 Call for Submissions: deadline on January 28
On Wednesday, 16 January 2013 at 10:42:56 UTC, Philippe Sigaud wrote: One day, we could organize a D conference in Europe :) There seem to be a good number of people from Europe here. Please do! :) Btw do we have someone from European D community here, who is familiar with conference organization nitpicks and can guide interested ones?
Re: Exceptional coding style
When you have a ton of similar lines of code which need to be edited in parallel, lining them up lets you edit all of them in one keystroke. Saves me quite a lot of annoying editing in the long run, actually. When you have a ton of similar lines of code, you'd better start thinking about templates or mixins :P Also, in regard of new approach to programming - is there a single method of interaction out there that is more efficient than plain text? It is kind of descriptive that we have so many different Desktop Environments and power users still prefer terminal everywhere.
Re: Shadowing of members
On Wednesday, 16 January 2013 at 08:18:53 UTC, bearophile wrote: mist: Many? Even single possible case is enough. And it has been mentioned already - generic code gen, i.e. permutations. Even one case is enough to kill it? Do you want to add that case in this ER, for future reference purposes? http://d.puremagic.com/issues/show_bug.cgi?id=4407 Bye, bearophile Yes and this is the very difference between compiler and static analysis tool, in my opinion. Compiler should never ever reject valid use cases, it does not matter how small chance of meeting those is. Also I am not Walter and second question has probably been targeted wrong :)
Re: Shadowing of members
On Wednesday, 16 January 2013 at 11:50:18 UTC, bearophile wrote: mist: Yes and this is the very difference between compiler and static analysis tool, in my opinion. Compiler should never ever reject valid use cases, it does not matter how small chance of meeting those is. In most cases debugging is an inherently statistical thing because large programs always contain many bugs. In programming life you can't work with absolutes, you should look at the probabilities too. Yes, I fully agree with you. That is way having a solid static analysis tool is must for low-level language. But compiler has different job and I like it UNIX-way. Also I am not Walter and second question has probably been targeted wrong :) Walter time is probably better spent elsewhere. If you have understood well what Walter meant, you should be able to write that a counterexample in that enhancement request. No idea how well I have understood, but I'll scratch a code example, no problem.
Re: Shadowing of members
On Wednesday, 16 January 2013 at 12:05:49 UTC, Jacob Carlborg wrote: On 2013-01-16 12:17, mist wrote: Yes and this is the very difference between compiler and static analysis tool, in my opinion. Compiler should never ever reject valid use cases, it does not matter how small chance of meeting those is. Clang contains a ton of warnings for code that could contain common errors. I mean, there's nothing wrong in having unreferenced variables but there are still compilers that warn about this. Also not that Clang has a static analyzer, in addition to the warnings and errors in the compiler. Well, that is probably the only thing I hate in Clang :) Also, I can't imagine a single valid use case for unreferenced variables in C/C++, so it is a bit different.
Re: Shadowing of members
On Wednesday, 16 January 2013 at 15:49:14 UTC, Jonathan M Davis wrote: On Wednesday, January 16, 2013 13:53:04 mist wrote: Well, that is probably the only thing I hate in Clang :) Also, I can't imagine a single valid use case for unreferenced variables in C/C++, so it is a bit different. RAII. - Jonathan M Davis Have just checked it - clang does not treat variable as unused if it does have use-defined destructor. Which makes sense from my understanding of word unused.
Re: Shadowing of members
On Wednesday, 16 January 2013 at 16:58:13 UTC, David Nadlinger wrote: On Wednesday, 16 January 2013 at 12:53:05 UTC, mist wrote: On Wednesday, 16 January 2013 at 12:05:49 UTC, Jacob Carlborg wrote: Clang contains a ton of warnings for code that could contain common errors. […] Well, that is probably the only thing I hate in Clang :) Actually, I found GCC to be much noisier in this (-Wall -Wextra) case; the Clang warnings are mostly of pretty good quality. Also, I can't imagine a single valid use case for unreferenced variables in C/C++, so it is a bit different. Variables only used as parameters to assert(), in release builds. This is somewhat annoying, as there isn't already an #if-block you could move them into, as for other similar cases involving conditional compilation. David Ah, good catch, glad I have not yet met such a case, I'd probably have raged a lot :) Well, both Clang and GCC are not perfect here. I have seen several times when -Werror policy got canceled because no acceptable workaround was thought of in time. And my development experience is rather small.
Re: D rawkz! -- custom writefln formats
Wow, cool stuff indeed. Preparing for DConf? :)
Re: Exceptional coding style
On Wednesday, 16 January 2013 at 18:42:38 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 18:38:21 UTC, Mehrdad wrote:
On Wednesday, 16 January 2013 at 11:00:48 UTC, mist wrote:
When you have a ton of similar lines of code which need to
be edited in parallel, lining them up lets you edit all of
them in one keystroke. Saves me quite a lot of annoying
editing in the long run, actually.
When you have a ton of similar lines of code, you'd better
start thinking about templates or mixins :P
Easy to say in theory, but makes absolutely no sense in many
cases. =P
Example:
boost::unordered_setint foo;
boost::unordered_mapint bar;
and now I want to change 'boost' to 'std' because C++11 came
out.
Templates? Mixins? wtf lol
Another example:
templateclass T struct foo
{
int x;
int operator+(int) const { }
int operator-(int) const { }
int operator*(int) const { }
};
templateclass T int fooT::operator+(int x) const { return
this-x + x; }
templateclass T int fooT::operator-(int x) const { return
this-x - x; }
templateclass T int fooT::operator*(int x) const { return
this-x * x; }
let's say now I want to add a new template parameter, class U,
to all the functions.
If you can teach me how templates or mixins would solve my
problem here I'd love to know.
This is a single template operator in D so it kind of solves the
problem. First is tricky, but is exactly the reason sometimes
types from external libs are used only via alias/typedef. I'd
prefer something like :%s/boost::unord/std::unord/g though :) But
well, if you are working with C++, then templates and mixins will
hardly solve most problems of course, because C++ templates sucks
and mixins do not even exist there.
Re: Exceptional coding style
On Wednesday, 16 January 2013 at 19:06:47 UTC, Mehrdad wrote: On Wednesday, 16 January 2013 at 18:57:06 UTC, mist wrote: This is a single template operator in D so it kind of solves the problem. First is tricky, but is exactly the reason sometimes types from external libs are used only via alias/typedef. I'd prefer something like :%s/boost::unord/std::unord/g though :) But well, if you are working with C++, then templates and mixins will hardly solve most problems of course, because C++ templates sucks and mixins do not even exist there. Yeah I'm working in C++, not D. But even if I was using D, there's no way in heck that I would use a _MIXIN_ for that: mixin(I'm not sure how this is supposed too be readable).unordered_map!(int) a; makes no sense to me at all, when I could just as well have said 'boost'. Also, the search/replace thing won't work so well for any real-world example (the second one is a lot closer to what I had in mind... you can't just replace T with T, U and expect it to work). So my point is: no, it's not a simple matter of abstracting things away. Lined-up text really DOES make certain tasks easier than they would be otherwise. Mixins and templates are tools to avoid copy-paste, there is no point to using them just for the sake of that. I have already mentioned that first example is not related to copy-paste and thus not fixable with that, it is more related to alias. Second is fixed perfectly in D using string mixins and single template unary operator with much more readable code. My point is - when you have a lot repetitive text pieces in your code, it is much better in longer scope to use advanced language tools instead of advanced editing tools. And this is one place where D is so superior do C++. I must admit I'd prefer to have template mixins allowed for statements to minimize string mixin usage but it is still much much better than copy-paste in my opinion.
Re: Exceptional coding style
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote: And extra vertical spaces are like semantic formatting tools for plain text - can group related blocks perfectly and speed up reading. The idea of not wasting lines doesn't go against the idea of adding blank lines to create code paragraphs. When you are adding a line to divide chunks, you are not wasting vertical space, it's a well used line :-) Bye, bearophile Well, I would not rant about this if not his actual example in Spacing block. This very example of bad code has every empty line added right where it fits. And good one is a mess that hurts my eyes when I try to concentrate on some distinct parts.
Re: Exceptional coding style
On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote: This generally comes up as an argument in these discussions, but I don't buy it. Not all development is done on a desktop with a huge screen. And even then, there is always something to put on it. What window manager are you using? Well, I hardly can imagine rationale behind using netbook for serious development aside from being on trip. Even being forced to work in ssh to some legacy shell ( I have that unpleasant experience :( ) usually limits your term width, not height. I am using Gnome Shell, but working mostly in full-screen undecorated terminal. It is approximately 75 to 85 lines of vertical space in my setup.
Re: Exceptional coding style
Well, probably I am playing good vision nazi here, as 12 font size seems HUGE to me, far beyond the comfort zone.
Re: DConf 2013 Call for Submissions: deadline on January 28
I'd also like to mention that now video recordings are planned and thus actual audience is a lot wider than just conference visitors.
Re: Exceptional coding style
On Tuesday, 15 January 2013 at 15:49:34 UTC, Russel Winder wrote: On Tue, 2013-01-15 at 15:07 +0100, monarch_dodra wrote: […] I do not know of any editor that does not support ctrl + scroll to change the font sizes on the fly. Emacs, VIM,… […] Your editor's font size should not be statically dictated by a single number. It depends on whether you want all the text to be a single size in which case yes just one number to set the font size ;-) monospaced fonts everywhere to rule them all! :)
Re: Exceptional coding style
On Tuesday, 15 January 2013 at 16:31:05 UTC, Russel Winder wrote: On Tue, 2013-01-15 at 17:02 +0100, mist wrote: […] monospaced fonts everywhere to rule them all! :) Monospace fonts are an aberration of the typewriter era. All text, including code, should be displayed in proportional fonts, in my case Ocean Sans Std on my machines. :O You are probably the very first programmer I have encountered so far that prefers proportional fonts for code. I need some time to even try to imagine how this may look.
Re: Exceptional coding style
On Tuesday, 15 January 2013 at 16:22:19 UTC, H. S. Teoh wrote: On Tue, Jan 15, 2013 at 11:56:34AM +0100, mist wrote: On Monday, 14 January 2013 at 23:57:18 UTC, Timon Gehr wrote: This generally comes up as an argument in these discussions, but I don't buy it. Not all development is done on a desktop with a huge screen. And even then, there is always something to put on it. What window manager are you using? Well, I hardly can imagine rationale behind using netbook for serious development aside from being on trip. Even being forced to work in ssh to some legacy shell ( I have that unpleasant experience :( ) usually limits your term width, not height. Heh. On the contrary, I find ssh to be a pleasant experience. Most GUI-heavy editors are so painfully inefficient to use that I find VT100 emulators far more pleasant to work with. I am vim user myself, but some legacy shells did not support more than 80 symbol width, thus the pain and according code style guidelines for us poor programmers on that project :) I am using Gnome Shell, but working mostly in full-screen undecorated terminal. It is approximately 75 to 85 lines of vertical space in my setup. I have a 1600x1200 screen, and an 18-point font, which gives me 93*41 terminal size. I find that just about right. (Like I said, I maximize everything, and anything significantly smaller than 18-point font, I find quite unreadable.) Well this is probably the main reason of different spacing tastes. I have literally twice as much vertical space fitting ( 1920x1080 @ 9pt ), can imagine how it makes you favor more compact style.
Re: Exceptional coding style
On Tuesday, 15 January 2013 at 16:51:34 UTC, Russel Winder wrote: On Tue, 2013-01-15 at 17:33 +0100, mist wrote: […] :O You are probably the very first programmer I have encountered so far that prefers proportional fonts for code. I need some time to even try to imagine how this may look. Use an editor like GEdit and change the font to a proportional one and admire how much nicer the code looks! GEdit is rather weak :( I am using VIM and Eclipse for coding and changed Eclipse font to monospaced Terminus font from default proportional. Problem I have with proportional fonts - they are not random-access ranges but sequential ones :) My brain is not capable of computing required offset for 30-40 proportional symbols in no observable time, contrary to monospaced. I still prefer proportional for books and web, of course, because it looks better and normal reading is indeed sequential.
Re: Mixin Template: cannot mixin scope(exit)?
I thought template itself should compile but its statement-like
instantiation should not.
By the way, if all you want is to split out some generic
statement block without using dirty string mixins, template
functions with alias parameters may do.
I.e. http://dpaste.1azy.net/68ad8133
Don't know what about inlining for it though.
Mixin templates are supposed to introduce *declarations* not
statements.
Eg. even this shouldn't compile, should it?
---
mixin template TimeExecution(T) if(isSomeString!T) {
import std.stdio;
writeln(T); // statement
}
---
