On Monday, 27 May 2013 at 07:32:15 UTC, TommiT wrote:
> I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla.

Well, technically we can, of course, it won't be that different from current situation (even more confusing though). Consistency issue Don has convinced me about though is that can't be such thing as "member initializer" for non-static members, as there is nothing to initialize there. Initialization happens when variable is created and that is defined by combination of T.init, struct literal syntax and constructors. So, contrary to usual local variable use case, the very same "member initializer" syntax does not really initialize anything, it just changes T.init value.

I don't feel it is important enough to actually change anything but worth remembering as language design nitpick.

Andrei Alexandrescu, el 23 de May a las 12:57 me escribiste:
> On 5/23/13 9:12 AM, Don wrote:
> >No, it's not, it's a fix plus a new misfeature.
> 
> Don, you're wrong. The feature is sensible. The problem with it is that it changes semantics of existing code.

Is not sensible for code review. For me the price to pay for a feature that add so little is too high. ROI ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Un paracaidista, que no deja de caer.
Lo que me lleva hacia arriba, es lo que me tira hacia abajo.

Dicebot, el 23 de May a las 16:42 me escribiste:
> something I may have actually used in real code writing a low-level networking library:
> 
> struct Packet
> {
> 	immutable etherType = 0x0800; // IPv4 by default;
> 
> 	// ...
> 
> 	this(bool IPv6)
> 	{
> 		if (!IPv6)
> 			return; // fine with default, same as Packet.init
> 		else
> 		{
> 			etherType = 0x86DD;
> 			// ...
> 		}
> 	}
> }

You can achieve the same with:

		if (!IPv6)
			etherType = 0x0800;
		else
			...

There is no need to double-initialize a immutable value. If you want to make it more explicit, just use something like:

enum defaultEtherType = 0x0800;

                if (!IPv6)
                        etherType = defaultEtherType;
                else
                        ...

I don't think that very rare use case, which is perfectly covered by
this "workaround" justifies the complexity added by this
double-initialization. Also code review becomes a nightmare, when I see
immutable something = 1; I can't assume something will be always 1,
I have to take a look at the whole code looking for constructors. That
SUCKS.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte

On Monday, 27 May 2013 at 17:08:19 UTC, Leandro Lucarella wrote:
> You can achieve the same with:
>
> 		if (!IPv6)
> 			etherType = 0x0800;
> 		else
> 			...
>
> There is no need to double-initialize a immutable value.

As I have already answered to Don it is all about T.init - only way to change it currently is to use initalizer syntax. It is hardly an issue with this use case - more like the general issue that such syntax was chosen for something that does not mean initialization.

Steven Schveighoffer, el 23 de May a las 23:53 me escribiste:
> On Thu, 23 May 2013 23:38:32 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> 
> >On 5/23/2013 7:38 PM, Steven Schveighoffer wrote:
> >>This is one change where ALL code broken by this change
> >>is fixable with a simple solution, and at some point, people
> >>will have to deal
> >>with this.
> >
> >Yes, but it is not so urgent as RIGHT NOW YOU MUST FIX IT. Hence, the warning.
> 
> If they aren't in the mood to change their code, they don't have to upgrade to the latest compiler.

That's completely FALSE. You might need some bugfixes! That view of "if you want to be up to date you have to be willing to update a lot of code" is really hurting D's stability.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hola soy Angie. Quería preguntarles como inserto un archivo .cab (paquete hecho en Visual Basic contiene una librería y un ocx) en Internet Explorer para después me deje trabajar en PHP con este .cab

Leandro Lucarella wrote:
> That's completely FALSE. You might need some bugfixes! That view of "if you want to be up to date you have to be
> willing to update a lot of code" is really hurting D's
> stability.

Evolution was never pain-free. The idea that D can thrive without adapting to it's changing environment will really hurt D's popularity now and in the future.

Isn't the feature you folks are talking about technically a bug-fix? IMO it's better to use an older compiler if you really need your work-arounds to function (granted there is proper docs), and let the rest of people adapt with the language.