Re: Formal Review of std.uni

[Jacob Carlborg]

On 2013-05-12 22:06, Dmitry Olshansky wrote:


std.json is another thing - 0x7F somehow is specifically tested as being
accepted as part of string literal. Yet ECMA script docs clearly state
that Unicode control characters are to be stripped even before lexing
(ignored even in literals).


That is my fault. There's a unit test for std.net.isemail that contains 
a 0x7F. std.json is somehow used in the auto tester. std.net.isemail 
broke the auto tester because of this. I haven't seen any JSON parser 
that doesn't accept 0x7F in a string literal.


--
/Jacob Carlborg

Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

[Jacob Carlborg]

On 2013-05-12 23:16, Nick Sabalausky wrote:


I *could* push that to the main mysql-native master repo right now
. But I'm hesitant
for one reason:

Since Phobos's and Vibe.d's sockets have incompatible APIs, my design
converts most of the types in mysql-native into templates. For example,
'Connection' becomes either 'Connection!mySQLSocketVibeD' or
'Connection!mySQLSocketPhobos'. The type 'Command' becomes either
'Command!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'. And the
same goes for most other types, such as Row, ResultSet, etc.

That is the only breaking change, but depending how your code uses
mysql-native, it can be a very significant breaking change.


Why don't you just relay on a version flag? Is it really necessary to 
change this at runtime?


--
/Jacob Carlborg

Re: new DIP40: Template parameter deduction for constructors

[Jacob Carlborg]

On 2013-05-13 04:37, Timothee Cour wrote:

A proposed feature of C++14 is to introduce template parameter
deduction for constructors, see paper, mentioned here. The idea is to
deduce template parameters when calling a constructor given the
arguments given to the constructor, whenever possible. A compile error
occurs when the deduction is ambiguous. The benefits would be:
* make the code more DRY
* make boilerplate of class instantiators unnecessary in most cases
(they're all over phobos, eg: std.typecons.tuple,
std.typecons.rebindable etc)
* make D more consistent: it deduces template parameters for
functions, so why not for constructors, when this is unambiguous?
* it won't break any code.
Note, just as for deduction of normal functions, it should work with 0
or more template parameters specified (ie the first k>=0 templates may
be provided).


I definitely want this.

--
/Jacob Carlborg

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)

[deadalnix]

On Sunday, 12 May 2013 at 20:28:56 UTC, Walter Bright wrote:

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:
Bartosz, Walter and I reached a similar design a few years 
ago. We just thought

it complicates things too much for what it does.


I've been working in the background on a scheme that can infer 
uniqueness. The beauty of it is it will not require visible 
language changes - it's just that things that didn't compile 
before now will. It won't solve all the problems, but I'm 
hoping it'll solve enough that the rest will not be more than a 
minor annoyance.


For a trivial example,

shared p = new int;

would work, as 'new int' would be inferred to be unique, and a 
unique pointer can be implicitly cast to immutable or shared. 
This plays to D's strength with function purity, transitive 
const/immutable/shared, attribute inference, etc.


It smell like an ad hoc solution that will be completely 
undefined.

Re: rename our github organization?

[Dicebot]

On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


Package maintainers will need to update build scripts but that is 
expected. I am all for it.

Re: new DIP40: Template parameter deduction for constructors

[Peter Alexander]

On Monday, 13 May 2013 at 02:39:22 UTC, timotheecour wrote:

The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.


This DIP is lacking in detail.

struct A(T1)
if(!is(T1==float))
{
this(T2)(T2 a, T1 b){}
this()(T1 b){}
this()(){}
}
struct A(T1)
if(is(T1==float))
{
this()(){}
}

auto a=A(1,1.0); //deduced to A!(double)(1,1.0)
auto a=A(1.0); //deduced to A!(double)(1.0)
auto a=A(); //error: T1 cannot be deduced.


How does the compiler decide which templates to attempt to 
instantiate? Does it just ignore conditional compilation 
conditions? If so, what would it do with this?


struct A(T)
if (is(T==float) && is(T!=float))
{
this()(T a) {}
}


If the conditions are ignored then it will match this 
uninstantiable template. If it doesn't ignore the conditions then 
how does it determine T ahead of time to evaluate the conditions?


One possible solution could be to first ignore the conditions, 
match the constructor, then check that the condition is okay. 
This is an extension on how normal function type deduction works 
though, so whatever mechanisms you have in mind need to be part 
of the proposal.

Re: rename our github organization?

[Andrew Gough]

On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


+1

Also rename D-Programming-Deimos to dlang-deimos (or better 
dlang-ext) while you're at it.

Re: rename our github organization?

[Dejan Lekic]

On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


+1
Makes sense to me.

Re: DConf 2013 keynote

[Iain Buclaw]

On 12 May 2013 19:08, Walter Bright  wrote:

> On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:
>
>> Second, in the Q&A session of your talk, you said, "I'm sorely tempted to
>> say
>> that real men don't use IDEs..."
>>
>
> Yes, but I said that as a joke.
>
>

As we all know that real men use vim.   :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)

[Andrei Alexandrescu]

On 5/13/13 3:06 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 20:28:56 UTC, Walter Bright wrote:

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:

Bartosz, Walter and I reached a similar design a few years ago. We
just thought
it complicates things too much for what it does.


I've been working in the background on a scheme that can infer
uniqueness. The beauty of it is it will not require visible language
changes - it's just that things that didn't compile before now will.
It won't solve all the problems, but I'm hoping it'll solve enough
that the rest will not be more than a minor annoyance.

For a trivial example,

shared p = new int;

would work, as 'new int' would be inferred to be unique, and a unique
pointer can be implicitly cast to immutable or shared. This plays to
D's strength with function purity, transitive const/immutable/shared,
attribute inference, etc.


It smell like an ad hoc solution that will be completely undefined.


To me it sounds like anything but. Walter explained the idea to me and 
it's definitely worth exploring. We will work together on a DIP.


Andrei

Re: Numeric limits tracking

[David Nadlinger]

On Monday, 13 May 2013 at 00:00:54 UTC, Manu wrote:
Has this been discussed? It seems simple, and it's invisible to 
the language.


There is no such thing as a language feature invisible to the 
language – or at least there should not be. Even a feature, such 
as this, which only makes the language more permissive needs 
exact specifications, for all D compilers have to implement it in 
the same way.


David

Re: Numeric limits tracking

[deadalnix]

On Monday, 13 May 2013 at 12:37:34 UTC, David Nadlinger wrote:

On Monday, 13 May 2013 at 00:00:54 UTC, Manu wrote:
Has this been discussed? It seems simple, and it's invisible 
to the language.


There is no such thing as a language feature invisible to the 
language – or at least there should not be. Even a feature, 
such as this, which only makes the language more permissive 
needs exact specifications, for all D compilers have to 
implement it in the same way.


David


is(typeof()) say that any permissive change can also break code 
in D. This is our little specificity ;)

Re: DConf 2013 keynote

[Dmitry S]

I know some folks who use Sublime Text and love it.

On Mon, May 13, 2013 at 2:52 AM, Jacob Carlborg  wrote:

> On 2013-05-12 21:31, Nick Sabalausky wrote:
>
>  Looks interesting. Now that you mention it, I do seem to recall hearing
>> about it back then. Personally, I've been a huge fan of Programmer's
>> Notepad 2 . My #1 complaint about it though
>> is that it's Windows-only. I want to switch to Linux for my primary
>> system, but the lack of PN2 is one of the roadblocks (there are other
>> roadblocks, though).
>>
>
> Take a look at Sublime Text. It's ridicules fast and cross platform. The
> only problem is that it's not free. You can download it for free and
> dismiss a dialog popping up once in a while.
>
> http://www.sublimetext.com/
>
>
>  But these days I prefer RDMD-style approaches ("pass the one main
>> source file to a cmdline tool and it figures out the rest") because
>> they're trivially scriptable and don't cause a specific editor (or any
>> editor at all) to become a build requirement. I find that especially
>> important for OSS and cross-platform projects.
>>
>
> The problem here is when you need to use a couple of compiler switches.
> You need a file to put that in, usually a shell script. Unfortunately that
> doesn't work on Windows. So you need to duplicate that file for Windows.
>
> --
> /Jacob Carlborg
>

Re: clear() causes crash?

[Steven Schveighoffer]

On Fri, 10 May 2013 22:37:43 -0400, Denis Shelomovskij  
 wrote:



30.04.2013 1:04, "Luís Marques" " пишет:

This crashes in the last line of main:

 class A
 {
 void foo() {}
 }

 void main()
 {
 A a = new A();
 a.foo();
 clear(a);
 assert(a !is null);
 a.foo();  // crashes
 }

As far as I understand from TDPL book, this should not crash, but it
does (DMD64 v2.062, OS X). Am I misunderstanding clear()?


TDPL states that the object is required to be in a valid state.  This  
necessarily requires calling a constructor on an object, as an object has  
no valid initial state.


There are major issues with that requirement, though:

1. How to call a ctor for an object that does not have a default ctor?  In  
other words, it requires valid ctor parameters, which the runtime cannot  
possibly know.
2. What if the ctor adds the class instance to a global or some other  
rooted memory item?  That is, what if the entire point of clearing it is  
so it was not pointed to as being allocated, so the GC would remove it.


So the decision was made (correctly) to simply make any object that was  
destroyed be an invalid object.  structs will return to their .init value  
(which may also be invalid depending on the struct).



BTW, why not make clear also change 'a' to null?


That could also be done, but it is superficial:

auto b = a;
destroy(a);
b.foo();

The only valid thing to do with a after destroying it is to stop using it,  
and all other references to that instance.




Ideally is should throw with pretty message but it isn't implemented.  
See Issue 8139 - Make objects really disposable by addition of "Object  
finalized" assertion [1].


IMO, also `destroy` (renamed `clear`) looks like the worst mistake in D  
runtime and I'd recommend to not use it (or better recompile  
druntime+phobos without it for your own use). See Issue 9139 - `destroy`  
is dangerous and inconsistent [2]. Use  
`unstd.lifetime.finalizeClassInstance` [3] and friends for user-defined  
lifetime implementation to avoid serious problems.


[1] http://d.puremagic.com/issues/show_bug.cgi?id=8139
[2] http://d.puremagic.com/issues/show_bug.cgi?id=9139
[3]  
http://denis-sh.github.io/phobos-additions/unstd.lifetime.html#finalizeClassInstance




I'm curious why you think it is bad.  All you have said here is that it is  
bad, not why.  Even bug 9139 says "look at how horrible this is" but  
doesn't explain why.


The point of destroy is to call destructors without deallocation.  The  
original charter said to leave the object in a default state, but that  
requires re-calling the constructor.


In the latest iteration, it simply calls the finalize function in the  
runtime.  you are not supposed to use it after calling destroy.


Not being defensive, I simply don't understand the objection.

-Steve

Re: DConf 2013 keynote

[Matt Soucy]

On 05/13/2013 10:19 AM, Dmitry S wrote:
> I know some folks who use Sublime Text and love it.
> 
> On Mon, May 13, 2013 at 2:52 AM, Jacob Carlborg  wrote:
> 
>> On 2013-05-12 21:31, Nick Sabalausky wrote:
>>
>>  Looks interesting. Now that you mention it, I do seem to recall hearing
>>> about it back then. Personally, I've been a huge fan of Programmer's
>>> Notepad 2 . My #1 complaint about it though
>>> is that it's Windows-only. I want to switch to Linux for my primary
>>> system, but the lack of PN2 is one of the roadblocks (there are other
>>> roadblocks, though).
>>>
>>
>> Take a look at Sublime Text. It's ridicules fast and cross platform. The
>> only problem is that it's not free. You can download it for free and
>> dismiss a dialog popping up once in a while.
>>
>> http://www.sublimetext.com/
>>
>>
>>  But these days I prefer RDMD-style approaches ("pass the one main
>>> source file to a cmdline tool and it figures out the rest") because
>>> they're trivially scriptable and don't cause a specific editor (or any
>>> editor at all) to become a build requirement. I find that especially
>>> important for OSS and cross-platform projects.
>>>
>>
>> The problem here is when you need to use a couple of compiler switches.
>> You need a file to put that in, usually a shell script. Unfortunately that
>> doesn't work on Windows. So you need to duplicate that file for Windows.
>>
>> --
>> /Jacob Carlborg
>>
> 

It's really nice, even with the nagware, which isn't even that bad. It
only pops up something like every 50 times you save. Even better, it has
built in support for Makefiles within a project, and it's fairly
straightforward to work with other build systems. (I have a simple DUB
one working)



signature.asc
Description: OpenPGP digital signature

Re: DConf 2013 keynote

[sk]

Thank you, nicely explained.

Re: new DIP40: Template parameter deduction for constructors

[Timothee Cour]

Thanks for the feedback, I've clarified the deduction mechanism and
show how it falls back to normal function template deduction.

Re: I want to add a Phobos module with template mixins for common idioms.

[Tove]

On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote:

On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by 
example that the string solution can be typesafe, scalable and 
elegant.


OK, this is a basic implementation:
https://gist.github.com/someboddy/5557358

Before I can make the pull request, I still need to do 
documentation, add some asserts to make sure users don't 
declare methods or subtypes in the property declarations 
string, add some more unit tests, and add the other idiom(the 
singleton).


But, it's still enough for demonstrating that strings are not 
evil, and that their usage here does not brake type safety, 
scope, or anything else.


kickass technique, hope this get included soon, keep up the good 
work!

Re: DConf 2013 keynote

[Nick Sabalausky]

On Mon, 13 May 2013 08:52:47 +0200
Jacob Carlborg  wrote:

> On 2013-05-12 21:31, Nick Sabalausky wrote:
> 
> > Looks interesting. Now that you mention it, I do seem to recall
> > hearing about it back then. Personally, I've been a huge fan of
> > Programmer's Notepad 2 . My #1 complaint
> > about it though is that it's Windows-only. I want to switch to
> > Linux for my primary system, but the lack of PN2 is one of the
> > roadblocks (there are other roadblocks, though).
> 
> Take a look at Sublime Text. It's ridicules fast and cross platform.
> The only problem is that it's not free. You can download it for free
> and dismiss a dialog popping up once in a while.
> 
> http://www.sublimetext.com/
> 

Hmm, yea I've looked at that before. There's some nice things about it,
but honestly, I can't stand non-native UIs (both looks and behavior).
Plus the settings don't seem to work (tried changing one, saved,
restarted, and it had no effect), and the text seems a little blurry,
and I'm kind of uneasy about relying on closed-source for something I
rely on as much as a text editor. Don't like being completely at some
company's mercy for any changes/fixes I may need.


> > But these days I prefer RDMD-style approaches ("pass the one main
> > source file to a cmdline tool and it figures out the rest") because
> > they're trivially scriptable and don't cause a specific editor (or
> > any editor at all) to become a build requirement. I find that
> > especially important for OSS and cross-platform projects.
> 
> The problem here is when you need to use a couple of compiler
> switches.

That's not a true problem at all. Nobody ever said RDMD, or anything
else like it, can't be invoked from another tool to provide whatever
additional functionality is needed. In fact, such things already
exist. But try adding on functionality using IDE-based build tools
as a building block - *and* then make it work for anyone who uses a
different editor.

> You need a file to put that in, usually a shell script.
> Unfortunately that doesn't work on Windows. So you need to duplicate
> that file for Windows.
> 

If all you're doing is passing a few switches to a DMD/RDMD call,
then having both BAT and shell is absolutely trivial. I do it all the
time myself:

1. Replace the shebang line with @echo off
2. Replace "$@" with %*
3. If you invoke anything in the current dir, remove the prefixed ./
(or change it to .\)

Done. If you need anything fancier than that (like handling steps that
fail, or really any actual logic at all), then shell scripting is
probably not the best idea anyway - even if you don't care about
Windows at all. Just use a shell one-liner to invoke the real script.

*Or* you can just use (or create) any other compiler-invoking, or
RDMD-invoking, tool that provides whatever functionality your project
happens to need.

IDE-driven building is great...*if* it happens to already provide
everything you need (otherwise you might be pretty much screwed - and
yes, I've run into such problems before) *AND* you happen to be working
in isolation with nobody else ever needing to build your code.

Re: new DIP40: Template parameter deduction for constructors

[Steven Schveighoffer]

On Sun, 12 May 2013 22:37:43 -0400, Timothee Cour  
 wrote:



A proposed feature of C++14 is to introduce template parameter
deduction for constructors, see paper, mentioned here. The idea is to
deduce template parameters when calling a constructor given the
arguments given to the constructor, whenever possible. A compile error
occurs when the deduction is ambiguous. The benefits would be:
* make the code more DRY
* make boilerplate of class instantiators unnecessary in most cases
(they're all over phobos, eg: std.typecons.tuple,
std.typecons.rebindable etc)
* make D more consistent: it deduces template parameters for
functions, so why not for constructors, when this is unambiguous?
* it won't break any code.
Note, just as for deduction of normal functions, it should work with 0
or more template parameters specified (ie the first k>=0 templates may
be provided).


Definitely need/want this.

I say it is most definitely possible given how IFTI works (it must  
partially instantiate the template).  It should be noted that conditional  
compilation can stop this from working.  As a first step, it should have  
exactly the same rules as IFTI, assuming the constructor is the eponymous  
IFTI function.


BTW, related issue:  http://d.puremagic.com/issues/show_bug.cgi?id=6082  
with 4 votes so far


Added a link there.

-Steve

Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

[Nick Sabalausky]

On Mon, 13 May 2013 09:03:08 +0200
Jacob Carlborg  wrote:

> On 2013-05-12 23:16, Nick Sabalausky wrote:
> 
> > I *could* push that to the main mysql-native master repo right now
> > . But I'm hesitant
> > for one reason:
> >
> > Since Phobos's and Vibe.d's sockets have incompatible APIs, my
> > design converts most of the types in mysql-native into templates.
> > For example, 'Connection' becomes either
> > 'Connection!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'.
> > The type 'Command' becomes either 'Command!mySQLSocketVibeD' or
> > 'Connection!mySQLSocketPhobos'. And the same goes for most other
> > types, such as Row, ResultSet, etc.
> >
> > That is the only breaking change, but depending how your code uses
> > mysql-native, it can be a very significant breaking change.
> 
> Why don't you just relay on a version flag? Is it really necessary to 
> change this at runtime?
> 

As this is intended as a "core-ish" low-level lib for any MySQL-client needs, I 
didn't want to unduly preclude any potential use-cases, even if it's not a 
typical use-case.

However, since it isn't a typical use-case, maybe what I'll do is this:

- Use new names for all of the newly templated types: Ex: 'Connection'
becomes 'ConnectionX!mySQLSocketVibeD' and
'ConnectionX!mySQLSocketPhobos'.

- Require a -version to specify which socket type is the default, and then set 
up backwards-compatible aliases. So for example, if 
'-version=MySQLN_DefaultSocketVibeD' is used, then 'Connection' (for example) 
is defined as an alias to 'ConnectionX!mySQLSocketVibeD'.

- If a unified socket interface ever emerges, and obviates the needs for the 
templates, then these -version idents can just simply be ignored and output 
"that -version is no longer needed" pragma messages.

Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

[Nathan M. Swan]

On Sunday, 12 May 2013 at 21:16:33 UTC, Nick Sabalausky wrote:

There is need for mysql-native
 to support 
both

Vibe.d's sockets and Phobos sockets.

Since Phobos's and Vibe.d's sockets have incompatible APIs, my 
design
converts most of the types in mysql-native into templates. For 
example,

'Connection' becomes either 'Connection!mySQLSocketVibeD' or
'Connection!mySQLSocketPhobos'. The type 'Command' becomes 
either
'Command!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'. 
And the

same goes for most other types, such as Row, ResultSet, etc.



Does "incompatible APIs" preclude a design like this?

-
interface MysqlSocket {
// ...
}

class PhobosSocket : MysqlSocket {
this(std.socket.Socket _backend) {
// ...
}
// ...
}

class VibeSocket : MysqlSocket {
this(vibe.core.net.TCPConnection _backend) {
// ...
}
}
-

Sorry if I've overlooked anything obvious,
NMS

Re: new DIP40: Template parameter deduction for constructors

[Kenji Hara]

Currently conditional compilation would stop IFTI.

template foo(T)
{
static if (is(T == int))
void foo(T) {}
}
void main()
{
foo(1);   // shouldn't work
}

Same as above, DIP40 should prevent following case.

template foo(T)
{
struct foo
{
static if (is(T == int))
this(T) {}
}
}
void main()
{
foo(1); // also should not work
}

Kenji Hara

2013/5/14 Timothee Cour 

> Thanks for the feedback, I've clarified the deduction mechanism and
> show how it falls back to normal function template deduction.
>

Re: Migrating D front end to D - post Dconf

[Jesse Phillips]

On Saturday, 11 May 2013 at 15:09:24 UTC, Iain Buclaw wrote:
Actually, the more I sit down and think about it, the more I 
question
whether or not it is a good idea for the D D front end to have 
a dependency

on phobos.   Maybe I should stop thinking in general.  :)

Regards


Let me restate the issues to be clear on what I think is being 
said, and the my opinion.


== On GDC:

There is an flag to have the compiler built without dependencies 
of druntime/phobos. Someone interested in a Phobos free compiler 
would the be required to have Phobos to build their compiler.


- While this is the same person, I don't see that they will 
require the same restriction when building the compiler. My guess 
is the environment used to build the compiler has fewer 
restrictions, such as the having gcc/ubuntu available. Thus it is 
reasonable to expect them to have the needed libraries to build 
their compiler.


- Similarly, even if we restrict to just using druntime, the one 
interested in a druntime free compiler still runs into the issue.


== On Compiling older Compilers:

Checkout compiler source for an older compiler and gcc will build 
it. By switching to D, not only do we locate the source for the 
compiler we are building we must have the version of D used to 
build that compiler (or within the some window)


- I think it would be positive to say, each dmd version compiles 
with the previous release and itself (possibly with -d). This 
gives a feel for what changes are happening, and the more Phobos 
used the better.


- We can't eliminate the problem, if we only rely on druntime, 
everything still applies there. Instead we just need a consistent 
and/or well documented statement of which compiler versions 
compile which compiler versions.


In conclusion, it is a real problem. But it is nothing we can 
eliminate. We should look at reducing the impact not through 
reducing the dependency, but instead through improvement of our 
processes for introducing breaking changes. Such concentration 
will not be limited to benefiting DMD, but instead every project 
which must deal with older code in some fashion.

Re: RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

[Jacob Carlborg]

On 2013-05-14 01:53, Nick Sabalausky wrote:


As this is intended as a "core-ish" low-level lib for any MySQL-client needs, I 
didn't want to unduly preclude any potential use-cases, even if it's not a typical 
use-case.

However, since it isn't a typical use-case, maybe what I'll do is this:

- Use new names for all of the newly templated types: Ex: 'Connection'
becomes 'ConnectionX!mySQLSocketVibeD' and
'ConnectionX!mySQLSocketPhobos'.


That sounds reasonable.

--
/Jacob Carlborg

Re: DConf 2013 keynote

[Jacob Carlborg]

On 2013-05-13 23:52, Nick Sabalausky wrote:


Hmm, yea I've looked at that before. There's some nice things about it,
but honestly, I can't stand non-native UIs (both looks and behavior).
Plus the settings don't seem to work (tried changing one, saved,
restarted, and it had no effect), and the text seems a little blurry,
and I'm kind of uneasy about relying on closed-source for something I
rely on as much as a text editor. Don't like being completely at some
company's mercy for any changes/fixes I may need.


There are two kind of settings. System wide settings and user settings. 
I don't know if that had something to do with it. Don't know about the 
text, it looks good on Mac OS X.



That's not a true problem at all. Nobody ever said RDMD, or anything
else like it, can't be invoked from another tool to provide whatever
additional functionality is needed. In fact, such things already
exist. But try adding on functionality using IDE-based build tools
as a building block - *and* then make it work for anyone who uses a
different editor.


If I would use an IDE I would prefer it to invoke a build tool/rdmd, 
just because of this. I don't want to lock someone in, to force them use 
a specific editor/IDE.



If all you're doing is passing a few switches to a DMD/RDMD call,
then having both BAT and shell is absolutely trivial. I do it all the
time myself:

1. Replace the shebang line with @echo off
2. Replace "$@" with %*
3. If you invoke anything in the current dir, remove the prefixed ./
(or change it to .\)


But there's still two files that needs to be maintained. Then you need 
some linker switches, which are system specific. I'm not that 
comfortable with the linker on Windows so I'm not sure I always get the 
flags correctly. That's why I really would like to have a build tool 
that handles this. It should have a system independent way of specifying 
common flags, like which libraries to link with.


--
/Jacob Carlborg

most non-function templates could be advantageously replaced by function templates

[Timothee Cour]

Phobos has a number of *non-function template* traits (std.traits,
std.typetuple etc), eg:

 in std.traits:
template hasMember(T, string name) {
static if (is(T == struct) || is(T == class) || is(T == union) || is(T
== interface))
enum bool hasMember =
staticIndexOf!(name, __traits(allMembers, T)) != -1 ||
__traits(compiles, { mixin("alias Identity!(T."~name~") Sym;");
});
else
enum bool hasMember = false;
}


I see those *disadvantages* with non-function templates:

* syntax is less clear than regular function templates (there's no way to
tell the return type without looking at the code or using some convention
relating to the template name)

* they're not DRY, as the template name is typically repeated (maybe in
multiple places) inside the template body (hasMember appears 3 times here)

* behavior of templates is actually weird, for example:


 template A1(T){enum A1=0;}
template A2(T){enum B=0;}
template A3(T){enum A3=0;enum B=0;}
void main(){
enum a1=A1!int;//ok
enum a2=A2!int.B;//ok
//enum a3=A3!int.B;//Error: no property 'B' for type 'int'
}


Maybe this was for historical reasons (ie CTFE might've come after those
design patterns were invented).

I would propose to use *regular template functions* instead, whenever
possible (essentially for the ones that return a value):

For our example, this would become:

 bool hasMember(T, string name)(){
static if (is(T == struct) || is(T == class) || is(T == union) || is(T =
= interface))
return staticIndexOf!(name, __traits(allMembers, T)) != -1 ||
__traits(compiles, { mixin("alias Identity!(T."~name~") Sym;
"); });
else return false;
}
// can be used in exactly the same way:
static assert(hasMember!(A,"field"));


*Advantages*:
* clear syntax: returns bool, and body is simpler to read as well
* DRY: hasMember only mentioned once
* no weird behavior as above
* doesn't break any code as usage is the same (backwards compatible)

In fact, I was able to convert with no problems a number of other such
templates:
 staticIndexOf
 isSame
 expectType
 genericIndexOf
etc...

For the latter (genericIndexOf), the template body contained a clause like
that:
 enum next  = genericIndexOf!(e, tail).index;
enum index = (next == -1) ? -1 : 1 + next;
during conversion, I just had to add the line:
return Tuple!(int, "index",int, "next")(index,next);
which could further be simplified using a helper function as its a common
idiom, into:
return TupleNamed!("index","next")(index,next);


*Limitations*:
One typical case where this isn't possible is when a template defines an
type alias, eg:

template Iota(int stop) {
static if (stop <= 0)
alias Iota=TypeTuple!();
else
alias Iota=TypeTuple!(Iota!(stop-1), stop-1);
}