Re: SOLID principals in D
On Sunday, 17 June 2018 at 01:38:17 UTC, evilrat wrote: On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet wrote: Hi, I come from a C# background and have been looking at D. How well does D implement solid principals? I've grown to really enjoy the SOLID style. For those unfamiliar, SOLID is an acronym for: - Single purpose: Meaning every unit of code (whether it's a function or class) should only have one reason to change. - Open/Close principal: Things should be open to extension but closed to modification. The example I like to use is some sort of IConverter object. Things can implement IConverter, but if you need a new way to 'convert' things, you don't extend an existing object, but instead create a new class that implements IConverter. - Liskov substitution principle: Essentially says if I have a method/function that takes a base class, then the behavior of that method shouldn't change when passing in derived objects. I think the term people like to use is whether or not you use a base/derived class it shouldn't effect the 'correctness' of the program. - Interface segregation principal: Essentially breaking the program up into smaller interfaces. Sometimes only consistent of one or two methods/properties (can feed into 'S' of SOLID quite nicely). - Dependency inversion principle: Things should depend on abstractions not concretions. Strongly enables dependency injection. D seems to have all of the features *required* to make this happen, but I guess the real question is the last two, and more specifically the last one. I am still not a D pro, so some thoughts maybe a bit off... (intro part) The "true D" guru's would tell you "in D your typical code would be mostly ranges(or templates) instead of classes", there is a good portion truth, but IMHO I find it overly attached. D uses duck typing for ranges, which means for example very basic (input) range have this protocol of 3 primitives - popFront(), front, empty Ranges heavily used in conjunction with templates, and templates is static thing, but with clever use of duck typing and that range protocol usually you don't care about specific type at all when dealing with ranges. Of course there is polymorphic interface(as in C#) for ranges too. Now how it applies to S and O? Ranges is basically an essence of S principle, they do exactly single thing, and most functions taking ranges as well. Just look at this "Sort lines" or some other examples on main page: - stdin .byLineCopy .array .sort!((a, b) => a > b) // descending order .each!writeln; -- Thought I'd add a link to Walter's good article laying out the case for such component programming with ranges: http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321
Re: allMembers broke for __
On Sunday, June 17, 2018 01:02:17 DigitalDesigns via Digitalmars-d wrote: > On Saturday, 16 June 2018 at 23:33:13 UTC, Jonathan M Davis wrote: > > On Saturday, June 16, 2018 22:59:24 DigitalDesigns via > > > > Digitalmars-d wrote: > >> On Saturday, 16 June 2018 at 06:47:59 UTC, Jonathan M Davis > >> > >> wrote: > >> > On Saturday, June 16, 2018 06:08:17 DigitalDesigns via > >> > > >> > Digitalmars-d wrote: > >> >> When an identifier starts with __, allMembers does not > >> >> return it. This is very bad behavior! It can silently > >> >> create huge problems if the programmer is not aware of the > >> >> bug. > >> >> > >> >> Instead, if you want to keep the current behavior at least > >> >> create an error or warning rather than silently create a > >> >> bug to waste the users time tracking it down. > >> > > >> > I would point out that identifiers that start with two > >> > underscores are supposed to be reserved for the compiler. > >> > Declaring them yourself is begging for trouble in general. > >> > > >> > - Jonathan M Davis > >> > >> So, you are saying that it's ok to beat me over the head and > >> cause me trouble simply because I used __? Seriously? I > >> thought D was all about making the programmers life easier and > >> not more difficult! Thanks for letting me know! I guess it's > >> time to go back to C#. > > > > There's no need to be melodramatic. All I'm saying is that > > identifiers starting with __ are reserved by the language - > > just like they are in many C-derived languages (I would expect > > them to be reserved in C# as well, though I don't know for sure > > if they are). Whether __traits stuff should ignore such > > attributes, I don't know (I wouldn't have expected them to be > > ignored, and that does seem weird), but either way, if you have > > any variable names that start with two underscores (be they > > member variables or local variables or whatever), you're > > potentially declaring variables that are in conflict with stuff > > that druntime or the compiler itself declare, and you risk bugs > > by doing so. Even if __traits shouldn't just ignore those > > identifiers, you shouldn't be declaring any variables that > > start with two underscores. If you didn't know that before, > > then I'm sorry, but the spec mentions it, and now you know. > > > > https://dlang.org/spec/lex.html#identifiers > > > > - Jonathan M Davis > > If this was a sane language constraint then any identifiers > starting with __ that were not reserved would at least give a > warning but particularly give an error! Not fail silently and > break code in ways that cannot be determined otherwise. It's bad > enough that the whole template system cannot be properly debugged > but to silently ignore user identities that start with __ just > because is ignorant, and it's not being melodramatic. > > I've seen you state several times that D does certain things to > "protect" the user... and now you are justifying it attacking the > user. You can't have it both ways, which is it? > > __ is not an uncommon identifier prefix and to reserve it then > have code break in ways that are nearly undetectable and could > cause major bugs in complex programs is not sane. How about > reserve a special character for special identifiers and do a full > rename on the master branch and simply do away with the arbitrary > __ constraint? > > There are correct ways to solve the problem and incorrect. > Justifying incorrect ways when they are clearly incorrect is not > sane(but it is typical practice). Identifiers that start with two underscores should be very uncommon, because they're usually reserved in C-derived languages (though for better or worse, most such languages don't actually flag them as errors even though they're technically illegal). There's really nothing unique about D in that respect. I suspect the reason that it's not a compiler error in D to start an identifier with two underscores is because it would make it a pain for druntime, because - being the runtime for the language - there are a number of identifiers that it declares which start with two underscores, and if the compiler tried to make that an error in general, it would either have to know all of the identifiers that druntime used or somehow know that it was compiling druntime (and at least some of those identifiers are extern(C) so that they're not mangled based on the module they're in, making detecting that something is part of druntime more complicated). It also may be that it needs to be possible to declare identifiers that start with two underscores in order to link against code from C's runtime. I don't know. I don't disagree that it would be nice if the compiler made it an error if anyone tries to do that in their program, but given how that would affect druntime, I'm not sure how reasonable that really would be in practice even if it really should happen in principle. And in practice, programs that have identifiers that start with two underscores sho
Re: allMembers broke for __
On Sunday, 17 June 2018 at 01:02:17 UTC, DigitalDesigns wrote: If this was a sane language constraint then any identifiers starting with __ that were not reserved would at least give a warning but particularly give an error! Not fail silently and break code in ways that cannot be determined otherwise. It is undefined behavior to use ANY identifier with __ leading. C works exactly the same way.
Re: IOS support status
On Saturday, 16 June 2018 at 12:59:48 UTC, makedgreatagain wrote: On Saturday, 16 June 2018 at 10:40:44 UTC, Joakim wrote: On Saturday, 16 June 2018 at 08:10:35 UTC, makedgreatagain wrote: On Friday, 15 June 2018 at 14:50:08 UTC, Joakim wrote: [...] I dont know what to deal with global.params.targetTriple.isOSDarwin and global.params.targetTriple.isMacOSX when I try merge it into ldc/master. should I keep both or just one ? Darwin can generally imply either macOS, tvOS or iOS, as far as I can tell.
Re: SOLID principals in D
On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet wrote: Hi, I come from a C# background and have been looking at D. How well does D implement solid principals? I've grown to really enjoy the SOLID style. For those unfamiliar, SOLID is an acronym for: - Single purpose: Meaning every unit of code (whether it's a function or class) should only have one reason to change. - Open/Close principal: Things should be open to extension but closed to modification. The example I like to use is some sort of IConverter object. Things can implement IConverter, but if you need a new way to 'convert' things, you don't extend an existing object, but instead create a new class that implements IConverter. - Liskov substitution principle: Essentially says if I have a method/function that takes a base class, then the behavior of that method shouldn't change when passing in derived objects. I think the term people like to use is whether or not you use a base/derived class it shouldn't effect the 'correctness' of the program. - Interface segregation principal: Essentially breaking the program up into smaller interfaces. Sometimes only consistent of one or two methods/properties (can feed into 'S' of SOLID quite nicely). - Dependency inversion principle: Things should depend on abstractions not concretions. Strongly enables dependency injection. D seems to have all of the features *required* to make this happen, but I guess the real question is the last two, and more specifically the last one. I am still not a D pro, so some thoughts maybe a bit off... (intro part) The "true D" guru's would tell you "in D your typical code would be mostly ranges(or templates) instead of classes", there is a good portion truth, but IMHO I find it overly attached. D uses duck typing for ranges, which means for example very basic (input) range have this protocol of 3 primitives - popFront(), front, empty Ranges heavily used in conjunction with templates, and templates is static thing, but with clever use of duck typing and that range protocol usually you don't care about specific type at all when dealing with ranges. Of course there is polymorphic interface(as in C#) for ranges too. Now how it applies to S and O? Ranges is basically an essence of S principle, they do exactly single thing, and most functions taking ranges as well. Just look at this "Sort lines" or some other examples on main page: - stdin .byLineCopy .array .sort!((a, b) => a > b) // descending order .each!writeln; -- stdin is console input stream, what happens next? all four functions above operates on ranges, and you can clearly tell what is their purpose. In this simple example they started operate on stdin, but in no way limited to it. It can be file, network stream or whatever else as long it is implements range protocol. Even though these functions may have different interface this is still the possibility for open/close principle. (yep, I agree this isn't the best example) (sorry, this part is not about SOLID at all) This is how most of standard library built, sure this isn't C# BCL and there is so very few things comparing to it, and there is very few use of polymorthic types in it, but it is highly generic because of use of templates. But enough about standard library, you are not forced to do everything that way, there is of course classes and interfaces, they work same as in C#, mostly. In own code you can do pretty much anything you can in C# (not actually sure what you can't) using classes and interfaces. I skip the Liskov principle. Classes and interfaces is enough to cover it, but again D is not limited to them, so you may even find your own discoveries. A word about DI in both D and D in SOLID: This isn't actually limited to just classes, basically it means that you(client code) provide dependencies(whatever things needed to be operational) for function/class you use to do the work, so they don't just 'new' it on their own. There is even a DI framework[1] (don't mind the names in API, I think it is heavily inspired by Java's Spring) Since you are coming from C# background the current state of tooling may shock you, the standard library is not a swiss knife and doesn't have all the goodies BCL has, I even pointed out there is not that much OOP stuff and polymorphism in it. There is also some language design choices that may surprise(both good and not so good ways) you. [1] https://code.dlang.org/packages/aedi
Re: allMembers broke for __
On Saturday, 16 June 2018 at 23:33:13 UTC, Jonathan M Davis wrote: On Saturday, June 16, 2018 22:59:24 DigitalDesigns via Digitalmars-d wrote: On Saturday, 16 June 2018 at 06:47:59 UTC, Jonathan M Davis wrote: > On Saturday, June 16, 2018 06:08:17 DigitalDesigns via > > Digitalmars-d wrote: >> When an identifier starts with __, allMembers does not >> return it. This is very bad behavior! It can silently >> create huge problems if the programmer is not aware of the >> bug. >> >> Instead, if you want to keep the current behavior at least >> create an error or warning rather than silently create a >> bug to waste the users time tracking it down. > > I would point out that identifiers that start with two > underscores are supposed to be reserved for the compiler. > Declaring them yourself is begging for trouble in general. > > - Jonathan M Davis So, you are saying that it's ok to beat me over the head and cause me trouble simply because I used __? Seriously? I thought D was all about making the programmers life easier and not more difficult! Thanks for letting me know! I guess it's time to go back to C#. There's no need to be melodramatic. All I'm saying is that identifiers starting with __ are reserved by the language - just like they are in many C-derived languages (I would expect them to be reserved in C# as well, though I don't know for sure if they are). Whether __traits stuff should ignore such attributes, I don't know (I wouldn't have expected them to be ignored, and that does seem weird), but either way, if you have any variable names that start with two underscores (be they member variables or local variables or whatever), you're potentially declaring variables that are in conflict with stuff that druntime or the compiler itself declare, and you risk bugs by doing so. Even if __traits shouldn't just ignore those identifiers, you shouldn't be declaring any variables that start with two underscores. If you didn't know that before, then I'm sorry, but the spec mentions it, and now you know. https://dlang.org/spec/lex.html#identifiers - Jonathan M Davis If this was a sane language constraint then any identifiers starting with __ that were not reserved would at least give a warning but particularly give an error! Not fail silently and break code in ways that cannot be determined otherwise. It's bad enough that the whole template system cannot be properly debugged but to silently ignore user identities that start with __ just because is ignorant, and it's not being melodramatic. I've seen you state several times that D does certain things to "protect" the user... and now you are justifying it attacking the user. You can't have it both ways, which is it? __ is not an uncommon identifier prefix and to reserve it then have code break in ways that are nearly undetectable and could cause major bugs in complex programs is not sane. How about reserve a special character for special identifiers and do a full rename on the master branch and simply do away with the arbitrary __ constraint? There are correct ways to solve the problem and incorrect. Justifying incorrect ways when they are clearly incorrect is not sane(but it is typical practice).
Re: allMembers broke for __
On Saturday, June 16, 2018 22:59:24 DigitalDesigns via Digitalmars-d wrote: > On Saturday, 16 June 2018 at 06:47:59 UTC, Jonathan M Davis wrote: > > On Saturday, June 16, 2018 06:08:17 DigitalDesigns via > > > > Digitalmars-d wrote: > >> When an identifier starts with __, allMembers does not return > >> it. This is very bad behavior! It can silently create huge > >> problems if the programmer is not aware of the bug. > >> > >> Instead, if you want to keep the current behavior at least > >> create an error or warning rather than silently create a bug > >> to waste the users time tracking it down. > > > > I would point out that identifiers that start with two > > underscores are supposed to be reserved for the compiler. > > Declaring them yourself is begging for trouble in general. > > > > - Jonathan M Davis > > So, you are saying that it's ok to beat me over the head and > cause me trouble simply because I used __? Seriously? I thought D > was all about making the programmers life easier and not more > difficult! Thanks for letting me know! I guess it's time to go > back to C#. There's no need to be melodramatic. All I'm saying is that identifiers starting with __ are reserved by the language - just like they are in many C-derived languages (I would expect them to be reserved in C# as well, though I don't know for sure if they are). Whether __traits stuff should ignore such attributes, I don't know (I wouldn't have expected them to be ignored, and that does seem weird), but either way, if you have any variable names that start with two underscores (be they member variables or local variables or whatever), you're potentially declaring variables that are in conflict with stuff that druntime or the compiler itself declare, and you risk bugs by doing so. Even if __traits shouldn't just ignore those identifiers, you shouldn't be declaring any variables that start with two underscores. If you didn't know that before, then I'm sorry, but the spec mentions it, and now you know. https://dlang.org/spec/lex.html#identifiers - Jonathan M Davis
Re: allMembers broke for __
On Saturday, 16 June 2018 at 06:47:59 UTC, Jonathan M Davis wrote: On Saturday, June 16, 2018 06:08:17 DigitalDesigns via Digitalmars-d wrote: When an identifier starts with __, allMembers does not return it. This is very bad behavior! It can silently create huge problems if the programmer is not aware of the bug. Instead, if you want to keep the current behavior at least create an error or warning rather than silently create a bug to waste the users time tracking it down. I would point out that identifiers that start with two underscores are supposed to be reserved for the compiler. Declaring them yourself is begging for trouble in general. - Jonathan M Davis So, you are saying that it's ok to beat me over the head and cause me trouble simply because I used __? Seriously? I thought D was all about making the programmers life easier and not more difficult! Thanks for letting me know! I guess it's time to go back to C#.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 18:49:43 UTC, Steven Schveighoffer wrote: On 6/15/18 8:53 PM, Seb wrote: On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, Seb via Digitalmars-d wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: > For someone coming from a C# background there is some > > seemingly simple syntactic sugar missing from D. > > * The null conditional operator `?.` e.g. SafeAccess https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551 Didn't Andrei propose an Elvis operator some time ago? Whatever became of that DIP? T https://forum.dlang.org/post/ot1q8b$23pt$1...@digitalmars.com https://github.com/dlang/dmd/pull/7242 I think Razvan focused on other projects no one else bothered enough to write a DIP about this. I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve Yes, Andrei's proposal was for the equivalent of ?? in C#. int* p = null; int n = p ?: 42; assert(n == 42);
Re: @safe by default
On Saturday, June 16, 2018 21:08:27 Jacob Shtokolov via Digitalmars-d wrote: > On Saturday, 16 June 2018 at 17:46:56 UTC, Jonathan M Davis wrote: > > doing that with attributes is rather error-prone, because it's > > easy for folks reading the code to miss them, making it unclear > > that they're in effect, and because unfortunately most > > attributes cannot be reversed, mass-applying them like that can > > then cause problems down the line when you need the attribute > > to _not_ apply to a function. > > I completely agree with the second point - if we can't reverse > these attributes in random places, the feature doesn't make sense > at all. > > The first point, however, looks arguable to me. So I would say > that it strongly depends on the task: for example, in web > development there is absolutely no need to use pointers and other > unsafe features until you really need them. In this case it's > better to force safety for all functions by default, and it would > be hard to do if we need to mark every single function as @safe > (not that hard of course, but very unpleasant). The problem isn't whether changing the default is desirable. It's the fact that it's not at all obvious to anyone reading the code that that's what's happening - especially when you're dealing with stuff like github pull requests, where you're looking at a diff of the code and don't see the top of the file as part of the diff. This problem has popped up several times in druntime and Phobos where an attribute was mass-applied to a module or a struct, and it's caused varying levels of problems. Sometimes, it just means that an attribute ends up being applied locally in addition to being mass-applied, but in other cases, it's resulted in folks outright misunderstanding an aspect of the code that relates to the attribute that was mass-applied. Personally, I think that it's just plain bad practice to mass-apply attributes precisely because it causes confusion about the code. And I'd say the same even if all attributes were reversible. Being able to do something like pure(false) would definitely be useful with mass-applied attributes, but it wouldn't fix the maintenance problems that come from applying attributes in a completely different part of the file from the function being affected. So, while you're certainly free to mass-apply @safe (or any other attribute) if you think that that will improve your code, I'd advise against it. - Jonathan M Davis
Re: @safe by default
On Saturday, 16 June 2018 at 17:46:56 UTC, Jonathan M Davis wrote: I would point out that in general, doing that with attributes is rather error-prone, because it's easy for folks reading the code to miss them, making it unclear that they're in effect, and because unfortunately most attributes cannot be reversed, mass-applying them like that can then cause problems down the line when you need the attribute to _not_ apply to a function. That being said, @safe is pretty much the one with the least problems, because it's one of the ones that you can reverse by using @system or @trusted explicitly where needed. However, there is no way to turn attribute inferrence back on, so putting @safe at the top of a module that has templated functions where the @safeness really needs to be inferred based on the template arguments can be a problem (though it's not as big a problem as putting @trusted at the top of the module, since at least with @safe, it just means that you'd end up with templates that don't compile when they would have been inferred as @system, whereas with @trusted, you'd potentially be hiding memory-safety bugs). So, while putting @safe at the top of the module may very well be your best choice, be aware that mass-applying attributes like that _can_ cause problems. - Jonathan M Davis Thanks Jonathan! The case with templated functions indeed is not obvious. doing that with attributes is rather error-prone, because it's easy for folks reading the code to miss them, making it unclear that they're in effect, and because unfortunately most attributes cannot be reversed, mass-applying them like that can then cause problems down the line when you need the attribute to _not_ apply to a function. I completely agree with the second point - if we can't reverse these attributes in random places, the feature doesn't make sense at all. The first point, however, looks arguable to me. So I would say that it strongly depends on the task: for example, in web development there is absolutely no need to use pointers and other unsafe features until you really need them. In this case it's better to force safety for all functions by default, and it would be hard to do if we need to mark every single function as @safe (not that hard of course, but very unpleasant).
Re: @safe by default
On Saturday, 16 June 2018 at 18:47:10 UTC, Steven Schveighoffer wrote: I would just caution that this does not affect member functions, only module-level functions. You have to repeat the @safe: inside any structs or classes as well. Just tried that and it works very well (throws compilation errors): https://gist.github.com/run-dlang/ba59bcca4464d875f95f975d13bebe88 It seems that it works even for member functions! But still not sure about anonymous functions and delegates.
SOLID principals in D
Hi, I come from a C# background and have been looking at D. How well does D implement solid principals? I've grown to really enjoy the SOLID style. For those unfamiliar, SOLID is an acronym for: - Single purpose: Meaning every unit of code (whether it's a function or class) should only have one reason to change. - Open/Close principal: Things should be open to extension but closed to modification. The example I like to use is some sort of IConverter object. Things can implement IConverter, but if you need a new way to 'convert' things, you don't extend an existing object, but instead create a new class that implements IConverter. - Liskov substitution principle: Essentially says if I have a method/function that takes a base class, then the behavior of that method shouldn't change when passing in derived objects. I think the term people like to use is whether or not you use a base/derived class it shouldn't effect the 'correctness' of the program. - Interface segregation principal: Essentially breaking the program up into smaller interfaces. Sometimes only consistent of one or two methods/properties (can feed into 'S' of SOLID quite nicely). - Dependency inversion principle: Things should depend on abstractions not concretions. Strongly enables dependency injection. D seems to have all of the features *required* to make this happen, but I guess the real question is the last two, and more specifically the last one.
Re: SOLID principals in D
On Saturday, 16 June 2018 at 19:20:30 UTC, FromAnotherPlanet wrote: Hi, I come from a C# background and have been looking at D. How well does D implement solid principals? I've grown to really enjoy the SOLID style. For those unfamiliar, SOLID is an acronym for: - Single purpose: Meaning every unit of code (whether it's a function or class) should only have one reason to change. - Open/Close principal: Things should be open to extension but closed to modification. The example I like to use is some sort of IConverter object. Things can implement IConverter, but if you need a new way to 'convert' things, you don't extend an existing object, but instead create a new class that implements IConverter. - Liskov substitution principle: Essentially says if I have a method/function that takes a base class, then the behavior of that method shouldn't change when passing in derived objects. I think the term people like to use is whether or not you use a base/derived class it shouldn't effect the 'correctness' of the program. Also if there is any good literature that explains the 'D' way of going about these principals or even how it enhances them that would be helpful. - Interface segregation principal: Essentially breaking the program up into smaller interfaces. Sometimes only consistent of one or two methods/properties (can feed into 'S' of SOLID quite nicely). - Dependency inversion principle: Things should depend on abstractions not concretions. Strongly enables dependency injection. D seems to have all of the features *required* to make this happen, but I guess the real question is the last two, and more specifically the last one.
Re: D community's view on syntactic sugar
On 6/15/18 8:53 PM, Seb wrote: On Saturday, 16 June 2018 at 00:32:24 UTC, H. S. Teoh wrote: On Sat, Jun 16, 2018 at 12:20:35AM +, Seb via Digitalmars-d wrote: On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: > For someone coming from a C# background there is some > seemingly simple syntactic sugar missing from D. > > * The null conditional operator `?.` e.g. SafeAccess https://github.com/BBasile/iz/blob/7336525992cb178ead83a7893a5a54597d840441/import/iz/sugar.d#L1551 Didn't Andrei propose an Elvis operator some time ago? Whatever became of that DIP? T https://forum.dlang.org/post/ot1q8b$23pt$1...@digitalmars.com https://github.com/dlang/dmd/pull/7242 I think Razvan focused on other projects no one else bothered enough to write a DIP about this. I don't know if this is the same thing. I'm not a (recent) C# developer, but in Swift, ?. means something completely different from ?: in Andrei's proposal. -Steve
Re: @safe by default
On 6/16/18 10:02 AM, Jacob Shtokolov wrote: On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote: On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote: Is it possible to introduce a new parameter/flag to the compiler, to force all functions be @safe by default on a per-module basis? For example: ``` module mymodule; pragma(safe); We already have that, and with even shorter syntax: ``` module mymodule; @safe: [...] ``` :-) OMG! Didn't know that! xD Thank you Bastiaan! I would just caution that this does not affect member functions, only module-level functions. You have to repeat the @safe: inside any structs or classes as well. -Steve
Re: @safe by default
On Saturday, June 16, 2018 14:02:36 Jacob Shtokolov via Digitalmars-d wrote: > On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote: > > On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov > > > > wrote: > >> Is it possible to introduce a new parameter/flag to the > >> compiler, to force all functions be @safe by default on a > >> per-module basis? > >> > >> For example: > >> > >> ``` > >> module mymodule; > >> > >> pragma(safe); > > > > We already have that, and with even shorter syntax: > > > > ``` > > module mymodule; > > > > @safe: > > > > [...] > > ``` > > > > :-) > > OMG! Didn't know that! xD > > Thank you Bastiaan! I would point out that in general, doing that with attributes is rather error-prone, because it's easy for folks reading the code to miss them, making it unclear that they're in effect, and because unfortunately most attributes cannot be reversed, mass-applying them like that can then cause problems down the line when you need the attribute to _not_ apply to a function. That being said, @safe is pretty much the one with the least problems, because it's one of the ones that you can reverse by using @system or @trusted explicitly where needed. However, there is no way to turn attribute inferrence back on, so putting @safe at the top of a module that has templated functions where the @safeness really needs to be inferred based on the template arguments can be a problem (though it's not as big a problem as putting @trusted at the top of the module, since at least with @safe, it just means that you'd end up with templates that don't compile when they would have been inferred as @system, whereas with @trusted, you'd potentially be hiding memory-safety bugs). So, while putting @safe at the top of the module may very well be your best choice, be aware that mass-applying attributes like that _can_ cause problems. - Jonathan M Davis
Re: IOS support status
On Saturday, 16 June 2018 at 13:18:34 UTC, makedgreatagain wrote: On Saturday, 16 June 2018 at 12:59:48 UTC, makedgreatagain wrote: On Saturday, 16 June 2018 at 10:40:44 UTC, Joakim wrote: I dont know what to deal with global.params.targetTriple.isOSDarwin and global.params.targetTriple.isMacOSX when I try merge it into ldc/master. should I keep both or just one ? And should I keep merge USE_OSX_TARGET_REAL or the ldc master already fix this? if I do not use real type in IOS i can skip this ? No idea, I haven't really used iOS, as I haven't bought an Apple device in almost 15 years. It's your port, you get to make the decisions. :)
Re: Wouldn't it be far fetch for finalize to be allowed to call only attrubutes in certain context?
On 6/15/18 6:55 PM, 12345swordy wrote:
Example:
@nogc void stuff()
{
A.destroy(); //Call destructors that is marked with @nogc due to being
in context
}
Granted there is a risk of not calling all the destructors, but I think
that responsibility lies on the programmer when designing the class.
I think we can do this, but we don't need to integrate with ~this. Just
make a new function. e.g. destroy_hook or something.
The compiler already can distinguish the overloads and call the right
one, I think.
-Steve
Re: @safe by default
On Saturday, 16 June 2018 at 14:02:36 UTC, Jacob Shtokolov wrote: On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote: On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote: Is it possible to introduce a new parameter/flag to the compiler, to force all functions be @safe by default on a per-module basis? For example: ``` module mymodule; pragma(safe); We already have that, and with even shorter syntax: ``` module mymodule; @safe: [...] ``` :-) OMG! Didn't know that! xD Thank you Bastiaan! You're welcome! It could have been better documented probably, because I was just looking for it and still cannot find it. I remember having seen it so I'm quite sure it is in there somewhere. At least it could have been in https://dlang.org/articles/safed.html. Here is one reference from the forum: https://forum.dlang.org/post/nj73gp$1q3k$1...@digitalmars.com Ah, found it, at the very top of https://dlang.org/spec/attribute.html Yeah, it can be made more obvious.
Re: @safe by default
On Saturday, 16 June 2018 at 13:57:48 UTC, Bastiaan Veelo wrote: On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote: Is it possible to introduce a new parameter/flag to the compiler, to force all functions be @safe by default on a per-module basis? For example: ``` module mymodule; pragma(safe); We already have that, and with even shorter syntax: ``` module mymodule; @safe: [...] ``` :-) OMG! Didn't know that! xD Thank you Bastiaan!
Re: @safe by default
On Saturday, 16 June 2018 at 13:52:37 UTC, Jacob Shtokolov wrote: Is it possible to introduce a new parameter/flag to the compiler, to force all functions be @safe by default on a per-module basis? For example: ``` module mymodule; pragma(safe); We already have that, and with even shorter syntax: ``` module mymodule; @safe: [...] ``` :-)
@safe by default
Hi folks,
I know there were a lot of discussions on this topic, and it is
understandable that due to historical reasons the D language is
designed with C/C++ interop in mind, so it means that there is no
@safe by default.
However, I also see a lot of people who want this feature, and I
personally think that it would be great to have it, because it
would save a lot of time by marking all functions as @safe by
default, if it needs to.
It is also understandable that it's not possible to change this
behavior today, because of compatibility. That's true and that's
OK to be honest, nothing wrong with it.
I'm still learning D, so please accept my apologies if I don't
see the whole picture, and if the question is obvious in some
way, but I'd like to ask:
Is it possible to introduce a new parameter/flag to the compiler,
to force all functions be @safe by default on a per-module basis?
For example:
```
module mymodule;
pragma(safe);
class Foo {
// Already marked as @safe by "pragma(safe)"
void bar() {
...
}
}
// @safe by default
void fooBar() {
...
}
```
The same could be done to @nogc and maybe other attributes.
I know that probably I'm not the first guy who proposing that,
but to be honest, I didn't find any fresh discussion about it, so
just decided to ask here.
Thanks!
Re: IOS support status
On Saturday, 16 June 2018 at 12:59:48 UTC, makedgreatagain wrote: On Saturday, 16 June 2018 at 10:40:44 UTC, Joakim wrote: I dont know what to deal with global.params.targetTriple.isOSDarwin and global.params.targetTriple.isMacOSX when I try merge it into ldc/master. should I keep both or just one ? And should I keep merge USE_OSX_TARGET_REAL or the ldc master already fix this? if I do not use real type in IOS i can skip this ?
Re: IOS support status
On Saturday, 16 June 2018 at 10:40:44 UTC, Joakim wrote: On Saturday, 16 June 2018 at 08:10:35 UTC, makedgreatagain wrote: On Friday, 15 June 2018 at 14:50:08 UTC, Joakim wrote: [...] Thanks a lot, after I modify llvm/autoconf/AutoRegen.sh (to allow use the version of my pc), and regenerate config.guess, cmake build start to working. and now I get a old ldc version with betterC support. (I am not test it on iphone yet, but it can build). Good to hear. now I wish some maybe there is not much modify to bring the last ldc master to iphone(only betterC work still can do more stuff, with less bug compare to druntime). Looks like he modified about 35 files in ldc for his iOS branch, the diff is not that big. If you're diligent, you could probably port it to master in a day. I dont know what to deal with global.params.targetTriple.isOSDarwin and global.params.targetTriple.isMacOSX when I try merge it into ldc/master. should I keep both or just one ?
An (old/new?) pattern to utilize phobos better with @nogc
I think I have just found a pattern to ease the pain of @nogc
programming somewhat. Consider this:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.map!(num => num^^power)
) printf("%d\n", raised);
}
It won't compile, because the lambda argument on map uses the
local variable power. Compiler thinks it must allocate that
variable in heap, using gc, lest the lambda function could
overlive power.
So that is probably one big reason for complains about Phobos
when you can't use the garbage collector. This hurdle won't make
it useless, though. You can avoid the problem this way:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.zip(power.repeat)
.map!(arg => arg[0]^^arg[1])
) printf("%d\n", raised);
}
It works, but arg[0] and arg[1] are fairly much book examples on
how to NOT name your variables.
But with a little bit of help, the library can still do better:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.zip(power.repeat)
.map!(tupArg!((num, pow) => num^^pow))
) printf("%d\n", raised);
}
alias tupArg(alias func) = x => func(x.expand);
Yes, it makes the syntax heavier, and in a simple case like this
it's arguable whether it's worth it.
But for me at least, when the complexity of the map alias
parameter starts rising, having the ability to name your
variables definitely pays back.
What are your thoughts? Do you agree with this coding pattern?
Re: IOS support status
On Saturday, 16 June 2018 at 08:10:35 UTC, makedgreatagain wrote: On Friday, 15 June 2018 at 14:50:08 UTC, Joakim wrote: [...] Thanks a lot, after I modify llvm/autoconf/AutoRegen.sh (to allow use the version of my pc), and regenerate config.guess, cmake build start to working. and now I get a old ldc version with betterC support. (I am not test it on iphone yet, but it can build). Good to hear. now I wish some maybe there is not much modify to bring the last ldc master to iphone(only betterC work still can do more stuff, with less bug compare to druntime). Looks like he modified about 35 files in ldc for his iOS branch, the diff is not that big. If you're diligent, you could probably port it to master in a day.
Re: D community's view on syntactic sugar
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D. First of all, it’s not missing but deliberately not added for many reason, which I’m sure other folks from core team will provide and correct me where applicable. * The null conditional operator `?.` Might be interesting but we need to try more principled approach alng the line of Option!T type with nice accessors and maybe even make non-null a default. The latter will take not a single year though. But peppering language with more built-in magic is not our direction, I’m pretty certain of that. * Something like a `yield return` statement for coroutines. That was on the radar actually, and would encode stackless automation wrapped as InputRange. Problem is how to get it to be say forward range (i.e. state saving would really be nice to include). For stackfull we have std.concurrency.Generator in library code just fine (IIRC). T* he `async` & `await` keyword from C# make proactor pattern async code extremely easy to reason about. God please no. Look at Go’s popularity because of dead simple go routines and “async i/o is transparent and looks blocking but ain’t so”. We have at least vibe.d for that and possibly more. Also see Java doing fibers recently, and Kotlin did them just a year or so back. People love fibers and mostly dislike Futers/explicit async, and plain callbacks are obvious last resort that nobody likes. ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well. * a good syntax for properties so there's less code bloat. * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard GC allocator. Why can't we just have a special template of it? Is a good idea, but syntactic sugar is smallest part of this problem if at all. I have realized that I have become quite dependant on syntactic sugar to the point that it severely impacts my productivity when I work whitout. And these ones are my biggest obstacles when I try to work with D from a C# experience. Yeah it won’t be smooth then I could see. I think that C# really nailed down some of these particular examples except the last one of course. And I also think D could do a better job of embracing productivity through supporting syntax of common tasks and borrow from other languages in that regard. But the most important question is how other people feel about that. If people hate syntactic sugar D will never become that gem for me that I would like it to be. But if key people want it, it one day might.
Re: IOS support status
On Friday, 15 June 2018 at 14:50:08 UTC, Joakim wrote: On Friday, 15 June 2018 at 13:18:25 UTC, makedgreatagain wrote: On Friday, 15 June 2018 at 11:30:40 UTC, Joakim wrote: Sounds like something wrong in your environment then, as I just checked out his last llvm ios-release_362 branch in a linux/x64 VPS, ran the configure command from his llvm script (see link), ran make, and everything's building fine: https://github.com/smolt/ldc-iphone-dev/blob/master/tools/prepmake-llvm You'll have to investigate what's different about your build environment that you can't seem to build an almost-stock llvm 3.6.2. Thanks a lot, after I modify llvm/autoconf/AutoRegen.sh (to allow use the version of my pc), and regenerate config.guess, cmake build start to working. and now I get a old ldc version with betterC support. (I am not test it on iphone yet, but it can build). now I wish some maybe there is not much modify to bring the last ldc master to iphone(only betterC work still can do more stuff, with less bug compare to druntime).
Re: D community's view on syntactic sugar
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D. * The null conditional operator `?.` This has been discussed many times and would definitely require a DIP and a good usecase. I'm all in support for this one. * Something like a `yield return` statement for coroutines. D has ranges and doesn't need statemachines like C#. T* he `async` & `await` keyword from C# make proactor pattern D uses fibers and calling the yield() function has pretty much same behavior. The major difference is your async code looks synchronous and thus more natural. D is a clear winner on this one IMO. async code extremely easy to reason about. See above. * a good syntax for properties so there's less code bloat. I agree with this, but will probably never happen. * replacing `Allocator.make()` with `new!Allocator`. After all `new` can be concidered as just a wrapper around the standard Not sure about this. The less ties the language has to the library, the better. GC allocator. Why can't we just have a special template of it? Above. I have realized that I have become quite dependant on syntactic sugar to the point that it severely impacts my productivity when I work whitout. And these ones are my biggest obstacles when I try to work with D from a C# experience. I think that C# really nailed down some of these particular examples except the last one of course. And I also think D could do a better job of embracing productivity through supporting syntax of common tasks and borrow from other languages in that regard. But the most important question is how other people feel about that. If people hate syntactic sugar D will never become that gem for me that I would like it to be. But if key people want it, it one day might. All in all. D requires a DIP for each and very good usecase. Not just "I think they're useful and I'd like them"
Re: D community's view on syntactic sugar
On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote: For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D. * The null conditional operator `?.` Yeah, me too. I have to say that at least D is expressive enough to allow the safeAccess template, as mentioned before, although there are several drawbacks: it's in many cases sub-optimal, it's not autocompletion-friendly at all, it's less distinguishable from an operator. But well, really it's nice that it's possible as a template. No need to harass the language leaders for that.
Re: D community's view on syntactic sugar
On Saturday, 16 June 2018 at 05:48:26 UTC, Nick Sabalausky (Abscissa) wrote: But short of that...no sugar is likely to happen anytime soon that isn't library-based, I'm genuinely sorry to report :( Most of these just seem like an easy win on the attractiveness of D. Big benefits of language based sugar is good tooling and debugging support. Not only would that make the language more attractive to outsiders who did have those things in other languages and refuse to use D whitout, but if properly implemented limit the strain on the brain of the programmer which opens up D to a new set of programmers. The reason I don't like library support in particular because you can't alway rely on a library, they take some time setting up, and maybe the open source project you're contributing to doesn't want libraries whatever how small. When people do use a library there is always licencing to think about and maybe, just maybe they chose a library you're already familiar with and you won't have to re-learn known concepts from a different library. (This last one is a real dealbreaker for me) Maybe in time, if a particular library is proven to be superior over existing syntax it'll get language support. But with the mantra "fast code, fast" I'm frankly kind of disappointed that such desicions weren't done before. I realize I missed out on some very usefull libraries and I'll look in to them and most likely start using them, but untill most of these things are implemented I still have this sour feeling in my mouth. Maybe some syntactic sugar will solve that. :P
