Hi Brian —

Constrained generics are definitely intended as part of Chapel's (hopefully 
not-too-distant) future, but have not made it to the top of the list as of yet. 
 In prioritizing what to work on for any given release, we try to focus on 
those features and changes that we believe would make current and "on-deck" 
users (including ourselves) most productive based on their feedback and input; 
what we think would permit us to attract more users; and those features that 
are most likely to result in breaking changes if put off.  So far, constrained 
generics haven't been cited as a must-have feature for the first group, though 
we'd like it for our own sanity and to minimize (potential / likely) changes to 
libraries once they're in the language.  I'd like to think that we'll spend 
time on them in 2019, if not finish them, but I'm historically terrible at 
predicting the future, and some other nagging issues have dragged on longer 
than hoped (initializers, error-handling, managed classes, nil-checking).  I 
could say more about challenges we've had getting to them before now, but will 
stop here for the time being.


The best way to get a sense of what we're focused on for any six-month period 
is to take a look at the "proposed priorities" slides in the release notes from 
the previous release.  For example, the current stretch for our upcoming March 
release is characterized by these notes:  
https://chapel-lang.org/releaseNotes/1.18/08-priorities.pdf  As you'll see, 
constrained generics are on the "other priorities" slide in this deck in the 
"big ticket" category which tends to mean that if the right developer(s) get 
free of their current top priorities, this is something we'd likely try to have 
them work on.  That said, we use an agile development process, and get new data 
from users throughout the release cycle, so think of this as a statement of 
intention and hope rather than any kind of firm commitment (in either 
direction... i.e.,  input from someone like you could influence the decisions 
as well).


UFCS has been brought up from time-to-time with Chapel, but hasn't had a strong 
(enough) champion to get any significant headway to date.  I have to admit to 
being a bit hesitant about adding it, but must admit that that comes from a 
position that's partly ignorant of the tradeoffs and partly due to viewing it 
as being contrary to the K.I.S.S. principle (i.e., Chapel is pretty 
feature-rich as it is, so these days I tend to look for things to leave out 
rather than bring in).


Thanks for your questions and interest in Chapel,

-Brad


________________________________
From: Brian Rogoff <[email protected]>
Sent: Monday, January 7, 2019 8:54:06 PM
To: [email protected]
Subject: Constrained generics?

Hi Chapelers,
    One of the things I miss in Chapel from (Rust/Java/Scala/...) is a way to 
constrain my generic types. I know this feature is coming to C++ 20 via 
concepts; how about Chapel? I see it has been considered here 
https://github.com/chapel-lang/chapel/blob/master/doc/rst/developer/chips/2.rst 
but I haven't seen any mention of it on lists of future language updates.
[https://avatars0.githubusercontent.com/u/7597261?s=400&v=4]<https://github.com/chapel-lang/chapel/blob/master/doc/rst/developer/chips/2.rst>

chapel/2.rst at master · chapel-lang/chapel · 
GitHub<https://github.com/chapel-lang/chapel/blob/master/doc/rst/developer/chips/2.rst>
github.com
a Productive Parallel Programming Language. Contribute to chapel-lang/chapel 
development by creating an account on GitHub.



    Is there a list of the planned changes for Chapel somewhere? I can see the 
hundreds long "Feature Request" and "Language" labels in Github issues, but 
that's not the same as a "What can we expect in 2019" list.

    As long as I'm asking, has UFCS* ever been considered for Chapel?

-- Brian

* https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users

Reply via email to